-
Notifications
You must be signed in to change notification settings - Fork 1
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
proposal: consistent error handling with Ucanto.Result
#7
base: main
Are you sure you want to change the base?
Conversation
We had a quick huddle about `Ucanto.Result` inspired by a discussion in `w3infra` (storacha-network/w3infra#318 (comment)) and I committed to writing up a proposal describing the tradeoffs of using _only_ `Result` for error handling vs using `Result` plus normal JavaScript error handling. I've proposed we standardize on `Result` purity and offered to take a pass through the code to ensure we are wrapping all possible thrown errors in error `Result`s but want to get feedback from the team before I do that! Comments sincerely requested - I, for one, could pretty easily be swayed to the "error `Result`s for known errors, thrown errors for unexpected stuff" camp, so if you feel strongly please let us know!
Rendered HTML link for your perusing pleasure here: https://github.com/web3-storage/RFC/blob/proposal/ucanto-result/rfc/ucanto-result.md |
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.
yes! I agree, we also did that already in Filecoin and I was hoping to get it the default everywhere
I discovered an annoyance with the "Results only" error handling paradigm today: I was trying to implement a method in an interface ( I ran into the same problem updating Both of these approaches seem like reasonable short-term ways to get the code running. The second approach means I need to go back and update We could solve this by saying that interfaces like this should always accept Exhaustively specifying possible error types in interfaces seems like the cleanest way to do this, but is annoying, especially in a case where updating an upstream interface is non-trivial (ie, because you don't control it, or something similar) and in this case I genuinely don't know what to do - can't throw, can't return an unexpected error, don't want to just eat the error... @Gozala any thoughts on this? |
Introduce `UnexpectedError` to allow implementations to return errors that weren't anticipated in the interface definition. More information about this problem here: storacha-network/RFC#7 (comment) Also in this PR: 1) export plan.js as a module so callers can use error classes defined there 2) use `prettier` to make things prettier
Introduce `UnexpectedError` to allow implementations to return errors that weren't anticipated in the interface definition. More information about this problem here: storacha-network/RFC#7 (comment) Also in this PR: 1) export plan.js as a module so callers can use error classes defined there 2) use `prettier` to make things prettier
@alanshaw @Gozala and I had a quick huddle about
Ucanto.Result
inspired by a discussion inw3infra
(storacha-network/w3infra#318 (comment)) and I committed to writing up a proposal describing the tradeoffs of using onlyResult
for error handling vs usingResult
plus normal JavaScript error handling.I've proposed we standardize on
Result
purity and offered to take a pass through the code to ensure we are wrapping all possible thrown errors in errorResult
s but want to get feedback from the team before I do that!Comments sincerely requested - I, for one, could pretty easily be swayed to the "error
Result
s for known errors, thrown errors for unexpected stuff" camp, so if you feel strongly please let us know!