proposal: consistent error handling with Ucanto.Result
#7
Conversation
We had a quick huddle about `Ucanto.Result` inspired by a discussion in `w3infra` (storacha/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 |
|
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/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/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.Resultinspired by a discussion inw3infra(storacha/w3infra#318 (comment)) and I committed to writing up a proposal describing the tradeoffs of using onlyResultfor error handling vs usingResultplus normal JavaScript error handling.I've proposed we standardize on
Resultpurity and offered to take a pass through the code to ensure we are wrapping all possible thrown errors in errorResults 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
Results for known errors, thrown errors for unexpected stuff" camp, so if you feel strongly please let us know!