-
Notifications
You must be signed in to change notification settings - Fork 140
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
Wrap host env errors with external errors #2683
Conversation
43759e4
to
abb7402
Compare
Cadence Benchstat comparisonThis branch with compared with the base branch onflow:master commit 181924e Collapsed results for better readability
|
Codecov Report
@@ Coverage Diff @@
## master #2683 +/- ##
==========================================
- Coverage 78.57% 78.57% -0.01%
==========================================
Files 338 338
Lines 78216 78237 +21
==========================================
+ Hits 61456 61472 +16
- Misses 14474 14476 +2
- Partials 2286 2289 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
|
b2cd9a8
to
fe2ba63
Compare
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.
The convention for runtime interface functions is that:
- Errors returned from the function are user errors
- Panics are internal errors (e.g. implementation bug)
For example, when a requested block does not exist, the implementation of GetBlockAtHeight
can return an error indicating that.
Why do we wrap paniced errors (internal errors) as external errors? To differentiate that they did not originate in Cadence itself?
Why would we wrap returned errors, i.e. classify user errors, as external errors?
Both questions probably stem from my lack of understanding what external errors are used/needed for.
So the problem is this convention is not always followed (and is not guaranteed to be followed either). There can be situations where certain user errors are also panicked, while internal errors are returned. This is a really grey area, sometimes a 'user error' to the host-env, etc. could actually be wrong information being sent by Cadence such that it's actually an internal error for the user.
Cadence doesn't know if a returned/thrown error is actually an internal error or a user error (unless it was originated from Cadence). So there's this "external error" category where it just says it's an error that came from outside and Cadence can't determine which one it is. |
The real problem I think is, in the cadence code base, we use panics to propagate errors (rather than returning). So any un-categorized error creates a problem at the top of the call tree where all errors are handled. |
@SupunS Thank you for the great explanation, that makes sense! |
Closes #2682
Description
Wrap the errors returned from host-env using the external error.
This is already done for the errors panicked from host-env.
master
branchFiles changed
in the Github PR explorer