[tracking] Better error handling
cole-h opened this issue · comments
Cole Helbling commented
This is a general tracking issue for the removal of (or to at least greatly
diminish the presence of) unwrap
s and expect
s, to guard against runtime
panics.
Some tasks that come to mind:
- Convert all
Result<..., String>
types to beResult<..., Error>
and roll an
Error
enum for each place with a non-trivial amount of errors to handle- As a result (no pun intended), convert instances of
unwrap
/expect
,
wherever possible, to use the?
operator to propagate errors up Maybe useanyhow
to reduce boilerplate?
- As a result (no pun intended), convert instances of
- Remove as many instances of
unwrap
andexpect
as possible in order to
decrease the occurrence of panics- At the very least, convert
unwrap
s toexpect
s, to indicate what the problem was and where it occurred
- At the very least, convert
cc @grahamc
Graham Christensen commented
lgtm, but I strongly prefer the enum and impl From method of handling errors, the implementations are easy and a bit boilerplate heavy, but easy to understand and extend. I'd prefer going the route of more boilerplate but trivial to understand.