Errors are not the ugly part of the code. What makes a good error?
No one enjoys receiving errors when working with computers but:
I believe there are 2 things that could be worse than errors:
- if you fail silently
- OR if you proceed with the WRONG data/assumption
A good error message MUST always indicate:
WHY it went wrong and the computer can’t proceed? Context about the goal of the process being executed
HOW the error was detected? A map for finding the root cause and inspecting more. Stack trace, error code or even a state dump
WHAT can be done to resolve it? Suggestions for recovering or taking an alternative path to the goal
WHEN did the error happen? Usually in form of timestamps
WHO was trying to achieve the goal? Usually some form of identification like user id, session id or even name
There are too many examples of bad errors around us and too many systems fail to give a meaningful one.
Windows Blue Screen of Death (even has its own acronym BSOD) is probably one of the most cursed error messages. Speaking of Mac, you get clear actionable advice on kernel panic (sadly becoming more common these days). __ If there’s one key take aware from this article, I want it to be this: Errors are encountered by real users who have real goals. The error message is a communication method that is aimed to help users to continue their goal.
#somethoughtsofmine