Nobody in Web development? -- maybe. Nobody in system (storage / network / compute) or any other specialized highly-reliable system -- unlikely. In highly rel

Nobody in Web development? -- maybe. Nobody in system (storage / network / compute) or any other specialized highly-reliable system -- unlikely. In highly reliable systems this is already being done, except it's usually an afterthought, ad hoc, functionality added without any system or framework, and so it's hard to judge its performance because it's often partially interactive, and very uneven across different components. Any system that advertises itself as "HA" (for highly-available) will have some sort of a protocol for complex error recovery, except it's usually not a single program that's explicitly written with the purpose of definition and documentation of recovery process, instead different bits of this functionality are embedded in many different places across the entire surface of a program. A very common example that I had to implement myself multiple times: HTTP errors. These are usually very poorly reported by the HTTP client libraries. TLS handshake failed? -- you get some numerical exit code instead of proper error report, and so once you realize that this error happens every so often, you start writing code that digs up the internal state of the TLS library at the time of the error, finds the certificates involved and tries to trace down the chain of events leading to the problem. Similarly, various parsing and de/serialization errors... this stuff is usually atrocious in popular libraries. And in order to figure out why some JSON didn't parse the way you wanted, you need to write a lot of code to investigate and report the error properly. The most common cases I've encountered is when a client program expects a server to reply with a structured error message, but the message comes back botched, or an HTML page is sent instead etc. A lot of these things are quite predictable after some time of using the client, but in a situation where you wanted to properly report an error that was supposed to be encoded in some JSON message and instead you got an HTML page -- typically you end up reporting a wrong (and useless) error of failure of parsing HTML as JSON. To prevent that, you'd need a complicated recovery scheme that would anticipate such errors.