Alex
Over the years of reviewing code, I noticed that most of the people related to product development (designers, managers, engineers) ignore error handling. Honest question: why? This is one of the most critical parts of the software. This is what makes a product superior. I would forgive broken styling, but the way software handles possible errors is the overall quality marker for this software.If users don’t receive proper feedback on errors, including:
- clear notice that the requested operation has failed
- clear cause of the failure (was it the user’s fault or is it the system failure?)
- and instructions on what to do next to solve the issue
then such software is not intended to be used by humans.
Juan
Couldn’t agree more. I would say that maybe it’s because:
- it is hard. So many things can go wrong that it is sometimes overwhelming to even think about most of them
- it is very time time consuming. Huge chunks of code need to be designed, written and maintained to do proper error handling. This sometimes ends up “obscuring” application logic.
- more often than not, we tend to believe “this can’t possibly go wrong”, and if it does, “it won’t be that big a deal”.
- in some environments, the only way to be exhaustive, is to trace the call stack to see if something can fail (and what and why)
This can be mentally taxing. I’ve found that it is sometimes helpful to think about errors as part of the domain itself, and to model them as regular data, returned and moved around through the same channels. It doesn’t make it easier, but at least, maybe a little less tedious.
Alex
I would say it is really heavy work when the domain is designed without considering proper error handling. When it is encoded from day 1 and encouraged by the company culture, it is much easier to handle it. Still, great error handling takes time and requires a lot of thought process & care, but it is worth it, IMO. As a user, I greatly appreciate it. This is my personal litmus test for software quality.
Martin
This whole discussion (especially your last comment Alex) could be re-packaged for accessibility, localization, RTL, dark modes, and other less visible things as well. All of them are just as difficult when not designed properly from day 1, and for me, it’s also a big indicator of (FE) software quality. Different scales.