Replies: 4 comments
-
Some results from
|
Beta Was this translation helpful? Give feedback.
-
Results of the meeting with Riqi (Paras):
|
Beta Was this translation helpful? Give feedback.
-
Another idea that came up in the discussion, is to give users advice on why such an error usually occurs. It can be implemented as a new field ( One more idea is |
Beta Was this translation helpful? Give feedback.
-
The result from the call with @frol :
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Error Handling Issues and Proposal
What are the issues?
1. Not all the errors are typed
Nearcore JSON RPC Handlers (typed: [x] , untyped: [] ):
Example (query -> view_account that does not exist):
Visible to developer as:
It leads to code like this:
2. broadcast_tx_* errors are typed in a nested way
JSON RPC response example:
Issues of this approach:
3. No single pattern for error handling
3.1 JSON RPC Errors can be thrown in several places:
It leads to unexpected behavior. For example, when we are using sendJsonRpc method without wrapper methods, such as json-rpc-provider.query().
3.2 Not all the errors that thrown from near-api-js are TypedError's.
3.3 Errors can be reported from nearcore in several ways, which is confusing:
Proposal
Open questions
Breaking changes, what is the best way to introduce them?
Should we? add any additional info to the error?
cc @frol @khorolets
Beta Was this translation helpful? Give feedback.
All reactions