-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New error handling design #507
Conversation
src/utils/rpc_errors.ts
Outdated
export class ServerErrorContext { | ||
transactionHash?: string; | ||
errorPath?: Record<string, any>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
transactionHash
and errorPath
are only relevant to the broadcast_*
and tx
(EXPERIMENTAL_tx_status
) endpoints, so I would call it TransactionExecutionFailureContext
, and make both of the fields required. I guess errorPath
can be renamed to transactionExecutionError
(it will have either ActionError
or InvalidTxError
)
I Will request feedback after these changes: #515 (comment) |
This PR is stale because it has been open for 7 days with no activity. Remove stale label or comment or this will be closed in another 7 days. |
Update: Serhii will break out some code into separate PRs. |
This fix requires too many breaking changes that are hard to introduce properly. Some good parts will be cherry-picked in later PR's. |
message
andtype
became mandatory inTypedError
. It should prevent us from creatingUntypedErrors
, and errors without description in the future.errorPath
added to allServerErrros
's as a part oferrorContext
.ServerError
since it'sServerError
specific.Breaking Changes:
TypedError.message
became mandatory fieldTypedError.type
became mandatory fieldTypedError
toServerError
X_Error
toServerError
TypedError
is exported as a part ofnear-api-js
interface, but I don't think that it's intended to be used in other projects.