4 ms·
I think this article is great but it buries the lede. The cutesy errors are indeed bad but more important is being informative about what actually went wrong a
by munk-a 4y ago
I think this article is great but it buries the lede. The cutesy errors are indeed bad but more important is being informative about what actually went wrong and how to resolve it. A while ago I introduced a new error class hierarchy at <JOB> which introduced three distinct families of errors - one that was considered a user error (that would be thrown in response to some action that we can predict happening but not totally prevent), one that is considered to have a user friendly message but be generally unexpected, and anything else. If you try and insert something invalid into the DB you'll get a user unfriendly message - if, within the calling function, you know why your call to the DB would fail with a key collision (for instance) you can create a new chained exception off the original and rethrow with a human readable message - when it hits the top level of execution (assuming nothing catches it) then the error printing logic will iterate through the full chain and print everything human readable and dump the full traces of any errors not marked as user side.
This lets us quickly triage new errors (since known user errors are kept out of the main error log) and presents an easy way to convert logged errors to unlogged ones when we've determined the source of the issue (assuming it's an exception we're comfortable with - a lot of our "user" errors are server-side validation that should be prevented by client-side code).
It also forces any errors that we haven't specifically marked as human-readable to render as "Internal Server Error" which we hate along with supplying an easy route to provide a more meaningful error message.
I never, in my life, want to read an error message that starts with "GuzzleHttp encountered a malformed response from aws. ..." nor do I ever want to see "[SQL1002] The newly inserted row would violate constraint widgets_name_key" - write good errors.
- TheRealPomax 4y agoThis was a twitter thread, so not too surprising, but the concluding tweet went there too: "Good error messages explain what’s gone wrong, and give clear instructions for what to do next – and being cutesy rarely helps." and there's a link to https://alexwlchan.net/2020/10/the-importance-of-good-error-messages https://alexwlchan.net/2020/10/the-importance-of-good-error-... as the dedicated writeup (also from tweets) for that specific point.
- snapdaddy 4y agoI disagree with nearly every response in this thread (not yours). The 'cutesy' error messages are step 1 to providing a better user experience. 'This is awkward! Something went wrong and it's probably our fault :-(' is much better for users than 'Unexpected error occurred in logTicketResponse' And no, it isn't sufficient, but it is better. Providing useful error messages is really hard (and it sounds like your application does a good job of it), and we as software developers are not very good at it. For everyone who complains about the cutesy error messages, how much time are you spending in your own code to provide useful error messages that explain the problem and suggest resolutions?
- schwartzworld 4y ago> 'Unexpected error occurred in logTicketResponse' I prefer this one, despite the fact that users might like the "cutesy" option better. If the user creates a bugfix ticket, the more information the dev receives the better. When you receive a ticket that says "_____ didn't work" and nothing else, how are you supposed to act on that? When possible, error messages should include _something_ anything to make it actionable. An error code, a descriptive message. Your example tells me exactly where to look in the codebase. I don't care about the verbiage, but generic error messages are almost impossible to reproduce in many cases, and should only be used as a last resort.
- Nextgrid 4y agoAbsolutely not. A cryptic error message still provides value to the user even if they don't understand it. Not only can they search and ask about it (maybe someone else does know), but they can also figure out a workaround by observing the system and under which conditions the error arises. You don't necessarily need to know what "Error 0x12345" means, but if you notice that it only happens under certain conditions, you can now work around it by not running the system under said conditions. A bullshit error message on the other hand not only makes searching useless but also prevents the user from exploring towards a solution since they can't even tell different errors apart if they have the same generic message.
- dTal 4y ago