3 ms·

There are fundamentally two classes of error message: 1. Information that can help a technically engaged person debug a problem. 2. Information that can help

There are fundamentally two classes of error message: 1. Information that can help a technically engaged person debug a problem. 2. Information that can help a user of the system understand what they have to do the overcome the problem. Since most error messages are created by people responsible for debugging the system they tend to be of the 1st class. There has to be a way to provide different information based on who is getting the error.

tremon 4y ago
There's a fatal flaw in assuming that there's no overlap between groups 1 and 2.
- deleted 4y ago
  [deleted]
koblas 4y ago
The error message that is presented to the user should always be clear and helpful. When an error is presented to the user, you should have matching logging (e.g. sentry) that provides technical reporting on what happened. By having both solutions in place you have error handling that is complete and services both communities.
FridayoLeary 4y ago
There's also a third class which is “Oops! Something went wrong…” which basically means "i don't know. Try and reload the page." Why this is better then a simple "error" is beyond me, but its mildly fustrating.
mttjj 4y ago
> There has to be a way to provide different information based on who is getting the error. Yes, this concept exists. The error message that is shown to the user (number 2) is what's discussed in the article. The error message that an engineer or someone else debugging the system should get (number 1) is the full stack trace and data dump that should be sent to the application log at the same time that the user is shown the error dialog. Users can fix the problem by following the instructions in the error dialog and engineers or technical people can come back later and look at the more detailed stack trace to determine the best course of action.
MetaWhirledPeas 4y ago
> There has to be a way to provide different information based on who is getting the error. This is already solved. Provide one error to the user and another to your logging system. In the user error provide a mechanism to point you to the logged error (even a simple timestamp helps).
lupire 4y ago
It's easy. Just provide both, with mark-up to label them.

tremon 4y ago

There's a fatal flaw in assuming that there's no overlap between groups 1 and 2.

deleted 4y ago
[deleted]

koblas 4y ago

The error message that is presented to the user should always be clear and helpful. When an error is presented to the user, you should have matching logging (e.g. sentry) that provides technical reporting on what happened. By having both solutions in place you have error handling that is complete and services both communities.

FridayoLeary 4y ago

There's also a third class which is “Oops! Something went wrong…” which basically means "i don't know. Try and reload the page." Why this is better then a simple "error" is beyond me, but its mildly fustrating.

mttjj 4y ago

> There has to be a way to provide different information based on who is getting the error. Yes, this concept exists. The error message that is shown to the user (number 2) is what's discussed in the article. The error message that an engineer or someone else debugging the system should get (number 1) is the full stack trace and data dump that should be sent to the application log at the same time that the user is shown the error dialog. Users can fix the problem by following the instructions in the error dialog and engineers or technical people can come back later and look at the more detailed stack trace to determine the best course of action.

MetaWhirledPeas 4y ago

> There has to be a way to provide different information based on who is getting the error. This is already solved. Provide one error to the user and another to your logging system. In the user error provide a mechanism to point you to the logged error (even a simple timestamp helps).

lupire 4y ago

It's easy. Just provide both, with mark-up to label them.