Improve error handling #286
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* When a function already returns a `Result`, propagate errors instead of panicking with `expect` * For `NovaError::SynthesisError`, retain information about the original bellpepper error. Since `NovaError` implements `Clone` but bellpepper's `SynthesisError` does not, we keep the error information as a `String`. This commit only fixes low-hanging fruit in lib.rs, for functions that already return a `Result` and can easily propagate errors just by replacing `expect(...)` with `?`. There are still many `unwrap()` calls in functions returning `Result` in other modules, particularly gadgets. But I don't understand the code well in those parts, and I suspect some of those `unwrap()`s actually can't fail based on invariants of the code, so it makes perfect sense to leave them as is.
|
@microsoft-github-policy-service agree |
This was referenced Jan 3, 2024
hero78119
pushed a commit
to hero78119/SuperNova
that referenced
this pull request
Jan 5, 2024
…t#226) * Expose the last outputs and number of steps from RecursiveSNARK (microsoft#285) Both of these data are easily accessible, and could be very useful to clients: * Exposing the last outputs allows us to get the current state of the computation on the prover side without wasting energy recomputing it * Exposing the number of steps makes it easier to eventually pass `num_steps` into `CompressedSNARK::verify` * Improve error handling (microsoft#286) * When a function already returns a `Result`, propagate errors instead of panicking with `expect` * For `NovaError::SynthesisError`, retain information about the original bellpepper error. Since `NovaError` implements `Clone` but bellpepper's `SynthesisError` does not, we keep the error information as a `String`. This commit only fixes low-hanging fruit in lib.rs, for functions that already return a `Result` and can easily propagate errors just by replacing `expect(...)` with `?`. There are still many `unwrap()` calls in functions returning `Result` in other modules, particularly gadgets. But I don't understand the code well in those parts, and I suspect some of those `unwrap()`s actually can't fail based on invariants of the code, so it makes perfect sense to leave them as is. Co-authored-by: Francois Garillot <[email protected]> --------- Co-authored-by: Jeb Bearer <[email protected]>
huitseeker
added a commit
to huitseeker/Nova
that referenced
this pull request
Feb 14, 2024
See microsoft#222, the commit_open_prove_verify test is subsumed by the subsequent unit test. @tchataigner was right from the start.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Result, propagate errors instead of panicking withexpectNovaError::SynthesisError, retain information about the original bellpepper error. SinceNovaErrorimplementsClonebut bellpepper'sSynthesisErrordoes not, we keep the error information as aString.This commit only fixes low-hanging fruit in lib.rs, for functions that already return a
Resultand can easily propagate errors just by replacingexpect(...)with?. There are still manyunwrap()calls in functions returningResultin other modules, particularly gadgets. But I don't understand the code well in those parts, and I suspect some of thoseunwrap()s actually can't fail based on invariants of the code, so it makes perfect sense to leave them as is.