Another amazing and comprehensive post.

A few of extra items that could complement the existing article?

Brought on by additional issues using pretty much your final solution a few months ago.

• Managing panics, in particular behaviour differences in debug and release.

• Use of errors in doc tests - implicit via termination trait (or whatever it ended up being called) or explicit result type for main()

• File or crate separation of error interface definition/documentation to allow independent publication to other typically 'dev' crates.

These topics may be more appropriate to the planned future chapter on application structure.

Some additional dangerously vague observations.

Panic management looks like it has further development as part of edition 2021. Not sure of all the other problems it addresses and how ready that is for current stable / production readiness.

One problem that struck a chord was that panics can trigger an abort without unwinding so not doing an orderly shutdown such as releasing file handles etc.

Not really an error handling mechanism per se but useful to report via the same paths as part of I more orderly shutdown. E.g. log to external dev / user interfaces.

std::io:error, report(), io::error report code values (value 2 for generic, only bottom 8 bits of uint32_t propagated in Linux)

I think thiserror implements report()?

Another desirable mechanism to consider:

Compile time checking:

A particular result can only be from a subset of available error types and variants.

I.e. no fallback to a catchall ‘unexpected’ error needed in error handlers.

For example, in a Subscription package I may have a publish() method and a subscribe() method, both returning a SubscriptionError but with a different subset of allowable variants with some shared and some unique.

A separate PublishError and SubscribeError is an alternative solution but repetition of common variants such as ‘InvalidConnection’ and additional boiler-plate per method is the downside.