3 ms·

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 standa

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.