Timeline for What is best way to handling exceptions without users see errors for technical supports?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 6, 2019 at 11:22 | history | edited | Flater | CC BY-SA 4.0 | added 1 character in body |
| Nov 6, 2019 at 10:17 | comment | added | Flater | @gnasher729: Also note that in OP's example it's about an application that was given to the customer. The approach for a web service is different than for an application that a customer runs locally on their own hardware. In the latter case, the machine's administrator needs reasonable error messages to reveal the source of an issue (at the very least distinguishing internal issues from external ones) because otherwise the application is a nightmare to work with. | |
| Nov 6, 2019 at 10:12 | comment | added | Flater | @gnasher729: Selectively passing specific vetted exception messages to the user is a valid UX decision. Exceptions by their very nature entail describing what went wrong to someone. That may not always be the end user, but there are cases where the end user should be clued in. For example, I want my browser to tell me that there is no internet connection and my browser did not encounter an internal error itself, I don't want "an error occured - go fish!" with no clue as to whether it's an issue in the browser's runtime or an external dependency (in this case the internet connection). | |
| Nov 6, 2019 at 10:09 | comment | added | gnasher729 | Exceptions are there to make the app work. UX design decides what to tell the user in which situation. They shouldn’t be confused. | |
| Nov 6, 2019 at 10:06 | history | edited | Flater | CC BY-SA 4.0 | added 566 characters in body |
| Nov 6, 2019 at 9:41 | history | answered | Flater | CC BY-SA 4.0 |