You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #290 I plan to split the Error type into one for the frontend and one for the backend. In a weekly call Adria proposed that we incorporate stack traces on synthesize errors in order to make it easier to debug synthesize errors (which currently don't contain any information context).
application enters into an state that will generate an undesired non deterministic output (corruption&co),
we need a way to debug complex back traces
use operators (like impl<F: Field> Mul for Expression<F>)
Error when
you can do something with the result
But it's everything somehow mixed, or I do not see the logic of generating panics or returns errors in the current library. Anyway, let's say that in the case of Halo2, probably, the only error that really matters is in the proof verification, panic'ing or returning error in proof generation is just ok.
What is not implemented is something like SynthesisWithBackTrace(std::backtrace::Backtrace), and really does not seem to have any sense at all. So I'm now in the side of, if developer wants a stack trace for Error::Synthesis, just generating an Error::Other
In #290 I plan to split the Error type into one for the frontend and one for the backend. In a weekly call Adria proposed that we incorporate stack traces on synthesize errors in order to make it easier to debug synthesize errors (which currently don't contain any information context).
One possible crate we can explore is https://github.com/eyre-rs/eyre
The text was updated successfully, but these errors were encountered: