Improve error handling

[KokaKiwi]

Is your feature request related to a problem? Please describe.

Error reporting is a big part in user interaction, thus it would be greatly beneficial to improve error handling.
As in:

• Removing as much panic! or .unwrap/.expect as possible, both because panic is not a good error handling in Rust, as stated in Chapter 9: Error Handling of The Rust Book, and because panic error messages are generally hard to read for users
• Providing as much useful information to the user in case of an error happening for helping them to fix it.

Describe the solution you'd like

• Use as much as possible Result when doing error-handling (up to main which can return a Result btw!):
  • Using panic!/.unwrap/.expect only when getting hard errors which cannot be handled in a sane way (defined as "unrecoverable errors")
• Use helpful crates for doing nice error-handling, with these ones as suggestions:
  • miette: Kind of a successor to anyhow and many other error-reporting crates, became one of the most used crates in this category for some time already and with many contributors/maintenance:

    Fancy diagnostic reporting library and protocol for us mere mortals who aren't compiler hackers

  • thiserror: A really helpful crate which help designing app-specific errors without the hassle of implementing Error by hand, also integrate really fine with miette
  • tracing-error: Could be optional here, but it brings a nice bridge between the tracing crate and error-handling code.

Additional context

Kind of a repetition, but the Rust Book chapter on error handling is a really good lecture: Chapter 9: Error Handling of The Rust Book

[SachaMorard]

@KokaKiwi what do you think about this issue?
Is it still relevant?

[KokaKiwi]

Yeah I think it's still relevant, especially switching to miette diagnostics would help getting more useful error when showing them to the user (by adding color, context and other informations)

[KokaKiwi]

Also if we could get rid of all the panic in the code that would be way better but that's more of a long-term work to do