Software generally have means to detect errors, like catching exceptions, and these can be categorized :

  1. App cannot run, some prerequisite not met.
  2. App failed to start.
  3. App started but some parts aren't functional.
  4. Instant: User clicks something (expected for something to happen), but it didn't.
  5. Time consuming: User starts a task, but it fails in between.
  6. Everything works, but with some warnings.
  7. Something critical went wrong, app will crash.

Now, how shall one decide which error are to be notified, and which ones logged silently ?


I think in general, show an error if:

  • The error is understandable by the user;
  • The user can mitigate the error by performing an action or changing their behaviour;
  • The error will have an immediate impact on the user's experience.

but don't show an error if:

  • The error is technical and only understandable by a developer;
  • The error can be resolved automatically;
  • The error won't have any noticeable impact on the user's session, or on their immediate task.

Microsoft covers error messages in the Windows User Experience Interaction Guidelines. It goes without saying that you should try to predict and prevent errors in the first place.

| improve this answer | |
  • @Matt Obee, Shouldn't we show technical errors in human [non-tech] form? – Hemchandra Mar 31 '14 at 10:07
  • @Hem Yes, if the error has a noticeable impact on the user's experience and if it can be explained in a way that makes sense. – Matt Obee Mar 31 '14 at 10:30
  • I think every error has impact otherwise we call them warnings :) – Hemchandra Mar 31 '14 at 10:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.