Error Handling Tracker

[mmtftr]

Proposal Description

We have problems with error handling. This issue is a tracker that includes sub-issues that aim to improve error handling and visibility across the codebase.

Some overarching concerns:

• We use unwrap()s for Error's that can happen in all likelihood.
  • Solution: we should only be using panicking error handler functions when we are sure that the error has no chance of happening. Eg. casting a Sha256 hash to [u8; 32]
• We only have one error type, and it's way too cluttered. It's also not used properly everywhere.
  • Solution: separate the Error types into subtypes that we can easily compose using thiserror's #[from] attribute.
• We don't utilize source/backtrace features of std::error.
  • Solution: we should look into using libraries like eyre to build up error reports.
• We don't separate user errors from internal errors clearly, which can become a downstream problem for end users of the binaries.
  • Solution (Improved error handling in binaries #304): separate errors into Internal errors and user errors
  • Solution (extra): aid the user in solving the issues when it's a user error, generate an error debugging report when it's an internal error.

[ozankaymak]

https://docs.rs/eyre/latest/eyre/