How to present the untreated exceptions?

Question

Every application fails, it’s a fact. In a Windows desktop application, when an untreated exception bursts, the following explodes on the user’s screen by closing the program:

Is not a blue screen, however inconvenient, non-explanatory and generic. The irony is that a return is never given to the user (at least I have never been returned with a solution, as the message says).

Personally, on macOS the user experience is even worse! A message and various technical data that the end user has no idea of:

And this is not specific to desktop applications. Whenever something unexpected occurs, regardless of the architecture of the solution, it is common to read messages like:

• a fatal error occurred;
• an unexpected error occurred;
• unknown error;
• Oops, something went wrong;
• an error occurred and it will not be possible to continue, change the programmer.

Should untreated and unrecoverable errors be presented? Should they contain technical data and error codes? Should you have an option to contact the developer(s) of the application? What points should be observed when reporting this type of error?

_{I’m looking for solutions that are based on the heuristics of usability and user experience (UX). Fully opinionated or unsubstantiated responses will be negative; instead of posting as a response, we can discuss in the comments or on chat.}

Answer 1

I am not an expert in UX. For my taste, not talking much to the average user seems ideal in most cases. For technical user it can be useful to give information that helps him do something.

The exception mechanism is used for two things: indicating programming errors; and indicating abnormal situation found. Well, they also use it for other things, but the focus here is not to discuss this abuse.

Programming error has no reason to be informed in detail to the user. It has to log in and/or send it to the developer. My experience is that it rarely manages to be very specific in programming errors for the end user (and it is where for the programmer needs all this that the exception usually generates, in other types of error does not need anything of that monster generated in each exception).

Circumstantial errors should never break the application, should try to recover, even if it requires some intervention from the user. Do not treat this type of exception happens to be programming error.

Usually programming errors should be handled in a single location. You should not keep trying to deal with programming errors throughout the code base. There is no way to keep trying to recover, treat in a specific way or give a lot of information to the user.

Perhaps it was the case to be more transparent and to say that the error was of the programmer.

It is possible to ask feedback for the user of what he was doing besides sending to the developer as much as the application can collect on the issue. It seems that in macos is doing this, but not in an obvious way that encourages the user to do so.

Some people like to copy the screen to log in together, there are even those who can send a dump detailed of what happened. In general create the dump is very expensive for the application, so has application that can connect only at specific time.

There are applications that don’t break, they start all over again. Doing it right can be interesting. If the application stick with things hanging before restarting can cause problems. I’d rather let it break even.

But what little I’ve learned is that you have to test with users what works best. The details will make a lot of difference and here you won’t get a proper response with them. Overall it’s thinking about what’s useful for the user, not you. Think before you do, don’t go on automatic.

In UX questions I’d rather hear than talk :) I expect better answers.