5 ms·

There must be a middle ground between "Something went wrong, please try again later :)" and "TypeError: Cannot read property 'submit' of null" when performing a

There must be a middle ground between "Something went wrong, please try again later :)" and "TypeError: Cannot read property 'submit' of null" when performing an action. I sometimes hear the "best of both worlds" is something like logging all errors while showing optimistic errors to the users on frontend. This is somewhat fine for errors that happen on the backend, but catching browser errors is tricky because extensions can throw errors. On top of that a user might not be comfortable with you collecting errors that happen in their browser.

richardwhiuk 3y ago
"Something went wrong, please try again later :)" is cheap (try { } catch () { print "Something went wrong" }) "TypeError: Cannot read property 'submit' of null" is cheap (just render whatever error you get). Anything else is expensive, and probably doesn't gain you anything.
delecti 3y ago
Those are two ends of the spectrum of how to handle unknown errors, but ignore the other axis: known errors. The UI displaying a red text field saying "field whatever is required to continue" is just as much an error message, but it's clearly actionable. There are lots of reasonably actionable error messages in all varieties of UIs for expected error cases. I don't know that there's a lot of useful middle ground between your two examples though. By definition, a UI can't really give actionable advice on how to fix an error that it isn't programmed to expect.
- CapsAdmin 3y ago
  Yeah this problem is a little more complicated than what I mentioned. By all means map known errors, but does the fallback really need to be "something went wrong?" It was a bit of a rhetorical statement (or at least in my mind it was). Like how about "Something went wrong (see details)" or something to that effect? In my work experience some people are really dogmatic about the idea of not showing any sort of error messages to users whatsoever.
  - delecti 3y ago
    In my work experience, users will complain about any sort of message. We recently got a request to change a message of "OK" to something more detailed. What more do you want than a message telling you that the thing you were trying to do succeeded? So I'm very sympathetic to people arguing against showing error messages.
SoftTalker 3y ago
Yes, the user should see the former, and the application should log the latter. The user probably can't do anything about a null reference, so there's not a lot of benefit in providing this level of detail, and for most users it obscures the bigger point that "something went wrong."

richardwhiuk 3y ago

"Something went wrong, please try again later :)" is cheap (try { } catch () { print "Something went wrong" }) "TypeError: Cannot read property 'submit' of null" is cheap (just render whatever error you get). Anything else is expensive, and probably doesn't gain you anything.

delecti 3y ago

Those are two ends of the spectrum of how to handle unknown errors, but ignore the other axis: known errors. The UI displaying a red text field saying "field whatever is required to continue" is just as much an error message, but it's clearly actionable. There are lots of reasonably actionable error messages in all varieties of UIs for expected error cases. I don't know that there's a lot of useful middle ground between your two examples though. By definition, a UI can't really give actionable advice on how to fix an error that it isn't programmed to expect.

CapsAdmin 3y ago
Yeah this problem is a little more complicated than what I mentioned. By all means map known errors, but does the fallback really need to be "something went wrong?" It was a bit of a rhetorical statement (or at least in my mind it was). Like how about "Something went wrong (see details)" or something to that effect? In my work experience some people are really dogmatic about the idea of not showing any sort of error messages to users whatsoever.
- delecti 3y ago
  In my work experience, users will complain about any sort of message. We recently got a request to change a message of "OK" to something more detailed. What more do you want than a message telling you that the thing you were trying to do succeeded? So I'm very sympathetic to people arguing against showing error messages.

SoftTalker 3y ago

Yes, the user should see the former, and the application should log the latter. The user probably can't do anything about a null reference, so there's not a lot of benefit in providing this level of detail, and for most users it obscures the bigger point that "something went wrong."