3 ms·

I try put as much context as possible into my error messages, I serialize the request object too. I think this is because you shouldn't be debugging in producti

I try put as much context as possible into my error messages, I serialize the request object too. I think this is because you shouldn't be debugging in production.

mac01021 6y ago
The article is not talking about bugs or software errors. It's talking about how programs respond to exceptional conditions like malformed user input, missing config files, etc.
mumblemumble 6y ago
I draw a big distinction between user-facing error messages and dev- and ops-facing error messages. Back when I was doing desktop GUI apps full time, my standard pattern was to display a terse and readable error message, and provide a link the user could click to bring up a much more detailed error report. The more detailed report was purely for the benefit of tech support, and very, very few users would click it unless specifically told to. I'm no Web developer, but I imagine the equivalent for a Web app would be to display a terse error in the browser and save a verbose error in the logs.
- nicoburns 6y ago
  > I'm no Web developer, but I imagine the equivalent for a Web app would be to display a terse error in the browser and save a verbose error in the logs. Services like Bugsnag are designed for this use case. You can send them an error message with arbitrary JSON attached (cause of error, but also details on the logged in user, device, browser, etc). And then yes, generally a generic "Try again or contact support" error message presented to the user. It works quite well if/when they do contact support because you can lookup specifically what errors have been triggered by that user. Of course anything is better than nothing. When I took over this codebase its error handling strategy was "Don't show an error message at all and just keep retrying until it works". Which was fine for transient errors, but a nightmare when something did go wrong: the user report would usually be "the loading spinner just keeps spinning forever", and that was all you had to go on. Nightmare.

I try put as much context as possible into my error messages, I serialize the request object too. I think this is because you shouldn't be debugging in production.

mac01021 6y ago

The article is not talking about bugs or software errors. It's talking about how programs respond to exceptional conditions like malformed user input, missing config files, etc.

mumblemumble 6y ago

I draw a big distinction between user-facing error messages and dev- and ops-facing error messages. Back when I was doing desktop GUI apps full time, my standard pattern was to display a terse and readable error message, and provide a link the user could click to bring up a much more detailed error report. The more detailed report was purely for the benefit of tech support, and very, very few users would click it unless specifically told to. I'm no Web developer, but I imagine the equivalent for a Web app would be to display a terse error in the browser and save a verbose error in the logs.

nicoburns 6y ago
> I'm no Web developer, but I imagine the equivalent for a Web app would be to display a terse error in the browser and save a verbose error in the logs. Services like Bugsnag are designed for this use case. You can send them an error message with arbitrary JSON attached (cause of error, but also details on the logged in user, device, browser, etc). And then yes, generally a generic "Try again or contact support" error message presented to the user. It works quite well if/when they do contact support because you can lookup specifically what errors have been triggered by that user. Of course anything is better than nothing. When I took over this codebase its error handling strategy was "Don't show an error message at all and just keep retrying until it works". Which was fine for transient errors, but a nightmare when something did go wrong: the user report would usually be "the loading spinner just keeps spinning forever", and that was all you had to go on. Nightmare.