How to present the unhandled exceptions?

Navigation
2

Every application fails, it's true. In a Windows desktop application, when an unhandled exception pops up, the following explodes on the user's screen, closing the program:

It'snota blue screen , however inconvenient, non-explanatory and generic. The irony is that a return is never given to the user (at least they never returned me with a solution, as the message says).

Personally, in MacOS the experience for the user is even worse! A message and various technical data that the end user has no idea what it is:

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 occured;
  • Unknown error;
  • ops, something went wrong;
  • An error occurred and will not be able to continue, change the programmer.
asked by anonymous 06.10.2017 / 05:55

1 answer

4

I'm not an expert on UX. Pro my taste does not speak much for the average user seems to me ideal in most cases. For technical users it may be helpful to give information that will help them do something.

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

Programming error does not have to be informed in detail to the user. You have to log in and / or send it to the developer. My experience is that you can rarely be very specific about programming errors.

Circumstantial errors should never break the application, should attempt to recover, even if it requires some intervention from the user. Failing to handle this type of exception happens to be a programming error.

Generally, programming errors should be handled in one place. You should not keep trying to handle programming errors throughout any code base. There is no way to be trying to recover, treat specifically or give much information to the user.

Maybe it was the case to be more transparent and say that the error was 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 about the problem. It seems that in macOS it is doing this, but not in an obvious way that it encourages the user to do it.

There are those who like to copy the screen to log together, there are even those who can send a detailed dump of what has occurred. In general creating this ( dump is always very expensive for the application, so it has application that manages to connect it at specific time.

There are applications that can not be broken, start over again. If done right it can be interesting. If the application keeps things hanging before restarting it can cause problems. I'd rather let it break.

But the little bit 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 will not have a proper answer with them. Overall it is thinking about what is useful to the user, not to you. Think before you do, do not go automatic.

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

    
06.10.2017 / 06:32
VueJS v-select submit Options menu with setOnItemClickListener