Exhaustively define error types to improve correctness (security and stability) and maintainability

[frol]

Ideally, every function should return only what it can potentially return, meaning that there should not be a huge enum with all possible errors in the world (like ErrorKind in chain), instead, there should be granular types (it can even be just a struct, not an enum, e.g. in Rust standard library there is AddrParseError, which is struct AddrParseError(()))

@frol: I would like to ensure the exhaustiveness of the potential error responses. How realistic is this approach in your opinion in regards to the core?

@bowenwang1996: It may be possible, but will likely take several months to complete

#3788 (comment)

Pros:

• Methods are sealed and have clear possible outcomes
• Methods with clear outcomes are easier to compose with each other in a predictable way
• From a stability point of view, methods with clear outcomes are "tested" by Rust compiler for free (Rust compiler will guard us during refactoring ensuring that we handle all the corner cases)
• From a security point of view, methods with clear outcomes can be easier to reason about and do not have surprises (unhandled use-cases, especially in a long run)
• From API UX point of view, it is easier to reason about the possible outcomes and handle them exhaustively (Rust compiler will help us here again), and it is especially useful for our public APIs like JSON RPC (see nearcore doesn't return structured errors for most use cases of API #2976, feat(jsonrpc): Implement backwards compatible structured errors #3517, and Implement structured errors in view-client #3518)

Cons:

• It feels verbose to introduce a new error type when you don't have one that matches your use-case. This should be addressed by setting up a proper framework (hopefully refactor(jsonrpc): Initial refactoring for Structured Error handling for JSON RPC and ViewClient #3805 will pave the road here)

[volovyks]

@frol Is there a possibility that two or more functions will return the same error type? How we will manage them in this case?

[frol]

@volovyk-s If the methods share semantics, we can use the same error type, otherwise, we can compose the error types (extract common parts into a separate entity and implement simple wrappers for the specific needs of the functions)

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[bowenwang1996]

@frol what are the action items here?

[frol]

We strictly defined our JSON RPC layer errors and while we struggled to identify all the possible underlying error cases, we managed to handle those. This issue does not have any action items at the moment, so I am closing it.