feat: non-scary error handler

[onbjerg]

The errors displayed to users are good for debugging, but most of the time they are not errors in Foundry, but rather errors in their input. I think we should distinguish between these and display appropriate reports, because the current error handler really looks like something super fatal happened regardless of whether that is actually the case (e.g. by displaying what file and line it is on in Foundry itself).

For panics, the current error handler is used, and for non-panics a simpler custom error handler is used.

Because we probably still want to be able to go back to the old one, you can freely switch using FOUNDRY_DEBUG:

$ cast 4byte 0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925
Error:
Invalid selector: expected 8 characters (excluding 0x prefix), got 66 characters (including 0x prefix).

$ FOUNDRY_DEBUG=1 cast 4byte 0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925
Error:
   0: Invalid selector: expected 8 characters (excluding 0x prefix), got 66 characters (including 0x prefix).

Location:
   /home/oliver/Projects/github/foundry-rs/foundry/utils/src/selectors.rs:109

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

We can add more stuff onto the error reporter was we want (for example, we could handle specific errors in a special way) - currently it just displays the top-level error and its cause (recursively).

Note: The "Error:" is from Rust's Termination trait and we can't configure it - the only way around it is basically by not returning anything from main and instead catching the error ourselves.

Closes #2042

[onbjerg]

Thoughts on this @mattsse @gakonst?

[mattsse]

I like this,

does this also print the location that paniced? because that is useful to get started when a user reports an issue?

how does color_eyre::install() differ?

int. tests that check output fail now and need to be updated

[onbjerg]

@mattsse color_eyre::install installs both a panic handler and an eyre handler. If we're not in debug mode (FOUNDRY_DEBUG=1) then we just want the panic handler and defer to our own eyre handler for normal errors

[mattsse]

can we keep this? this is very helpful when a user reports an issue so we know where the panic happened and can start tracking it down

[onbjerg]

I think this makes it seem like it's always a Forge issue though - and this info can be surfaced if they run with FORGE_DEBUG=1 which is (imo) a better user experience.

So the behavior in this PR is:

• By default for errors we just print the error message (and any errors preceding that error etc.)
• If FORGE_DEBUG=1 (or any value, really) then we display the current error format (with location, backtrace stuff etc.)
• If it's a panic then it will display the error in the same manner as FORGE_DEBUG=1 but with an added message that says that this is an error they should report (because we ideally don't want to panic)

Makes sense?

[mattsse]

I think this makes it seem like it's always a Forge issue though - and this info can be surfaced if they run with FORGE_DEBUG=1 which is (imo) a better user experience.

agree

this makes sense!

[mattsse]

lgtm