I’ve learned to keep errors simple. I have found that the most important thing is to anticipate and trap the error. Reporting it is actually the simplest part o

I’ve learned to keep errors simple. I have found that the most important thing is to anticipate and trap the error. Reporting it is actually the simplest part of the thing. The kind of structure mentioned in the article, with things like contexts, and calling chains, is stuff that I did for years. In my experience, it had a glass jaw. It broke easily. The more complicated something is, the more places it has to break. Also, I found that I never, ever used it. The most introspection I ever did, was look at an error code. Where the error happened, was the important thing, and a symbolic debugger gave me that. These days, I just declare an Error-conformant enum, sometimes with associated data, and add a few computed properties or functions. It’s most important that I write my code to anticipate and catch errors. The report is always refined to be as simple and gentle to the user, as possible. The technical stuff, I have found, is best handled with a symbolic debugger. But that’s just me, and I know that the type of software that I write, is best served with that model. YMMV.