[ChrisMarshallNY]

I’m of the opinion that the best error handling, is to not encounter the error, in the first place.

That means good UX, intuitive interfaces, good affordances, user guidance (often, without requiring them to read text), and simplicity.

When an error is encountered, then it needs to be reported to the user in as empathetic and useful manner as possible. It also needs to be as “bare bones” simple as can reasonably be managed.

Designing for low error rates, starts from requirements. Good error reporting requires a lot of [early] input from non-technical stakeholders.

[pyfon]

Errors often come from the fact that we build on unreliable medium.

Lost packets, high latency, crashed disks, out of memory etc.

You can talk to your users sure but you need to handle this stuff at some level either way. Shit happens!

[ChrisMarshallNY]

Absolutely.

But we need to plan for it from Day One, and that can also include things like choosing good technology stacks.

Like I said, when inevitable errors happen, how we communicate (or, if possible, mitigate silently) the condition, is crucial.

[EDITED TO ADD] Note how any discussion of improving Quality of software is treated, hereabouts. Bit discouraging.

[pyfon]

Correct. What errors can happen PLUS how we communicate (and what we do: roll-back transaction? Etc.) PLUS how do we ensure correctness of both (sane programing language, good idioms, testing, proofs etc.)

[ChrisMarshallNY]

Anyone that has maintained a shipping product, can relate to this.

Often, there is disagreement over the definition of “bug.”

There’s the old joke, “That’s not a bug, it’s a feature!”, but I have frequently gotten “bug reports,” stating that the fact that my app doesn’t do something that the user wants, is a “bug.”

They are sometimes correct. The original requirements were bad. Even though the app does exactly what it says on the tin, it is unsuitable for its intended demographic.

I call that a “bug.”