[fizlebit]

Looks a bit like Rust. My peeve with Rust is that it makes error handling too much donkey work. In a large class of programs you just care that something failed and you want a good description of that thing:

  context("Loading configuration from {file}")

Then you get a useful error message by unfolding all the errors at some point in the program that is makes sense to talk to a human, e.g. logs, rpc error etc.

Failed: Loading configuration from .config because: couldn't open file .config because: file .config does not exist.

It shouldn't be harder than a context command in functions. But somehow Rust conspires to require all this error type conversion and question marks. It it is all just a big uncomfortable donkey game, especially when you have nested closures forced to return errors of a specific type.

[wazzaps]

You just described how the popular "anyhow" and "snafu" crates implement error handling

[fizlebit]

Even with anyhow there is a lot of boilerplate it seems to me dealing with crates that don’t use it. I haven’t tried snafu but its name does not inspire confidence.

Clanker (ai assistant) also love to unwrap and if you don’t catch them you have an abort waiting for you.

[jll29]

I like your "context" proposal, because it adds information about developer intention to error diagnostics, whereas showing e.g. a call stack would just provide information about the "what?", not the "why?" to the end user facing an error at runtime.

(You should try to get something like that into various language specs; I'd love you to success with it.)

EDIT: typo fixed.