1. 16
  1. 6

    My favorite is: “Something went wrong. Please try again later”, which is a standard quality of error messages in web applications, even from software molochs like MSFT. It’s like error handling is too expensive even for them.

    1. 6

      This is addressed in the article

      Before we start, let me clarify that this is about error messages created by library or framework code, for instance in form of an exception message, or in form of a message written to some log file. This means the consumers of these error messages will typically be either other software developers (encountering errors raised by 3rd party dependencies during application development), or ops folks (encountering errors while running an application).

      That’s in contrast to user-facing error messages, for which other guidance and rules (in particular in regards to security concerns) should be applied. For instance, you typically should not expose any implementation details in a user-facing message, whereas that’s not that much of a concern — or on the contrary, it can even be desirable — for the kind of error messages discussed here.

      1. 3

        Even if you buy into the security concerns, you can make a message that isn’t completely useless. At least categorize it into if the user did something wrong or not so they have a clue as to if they can do something or when “later” might be.

        1. 3

          The “something went wrong” class usually means an exception or similar, so a bug in the app. Later is after the devs get to that point in their exception tracker and fix it.

          1. 2

            so a bug in the app

            Except cases when it’s not a bug in the app,

            Later is after the devs get to that point in their exception tracker

            Except when it means “never”, because the user is one of 100 people across the whole world that are triggering the bug, and it’s not economically viable to allocate the time to fix the bug (too small number of users affected).

            1. 5

              In what case would it not be a bug? Showing such an error in a non-bug case would itself be a bug

              1. 4
                • Connection problems due to user’s ISP,
                • User uses a non-supported browser,
                • User uses an old version of the browser that doesn’t support some feature,
                • User uses a browser plugin that introduces some conflict with the app,
                • User uses an unsupported OS,
                • Some hardware driver in user’s OS is buggy,
                • I mean should I go on?
                1. 7

                  If any of those result in a generic error message from your app, then your app has a bug

                  1. 3

                    OK, here’s a real world thing that just came up. I was on American Airlines’ website last night checking the status of a flight for someone I had to pick up at the airport. It said they were 30 mins ahead of schedule so I shut the laptop and drove up there early. Indeed, the airplane was touching down at about the time I arrived.

                    Today, just now, I opened that laptop back up and decided to refresh that flight status page, just curious to see what their official arrival time was. I was greeted with: “Flight Status: Something Went Wrong. Our system is having trouble. Please try again or come back later.”


                    nah just the stupid website threw up a generic error message because i had the gall to hit “refresh” instead of going back to the homepage and rerunning the search.

                    But think how ridiculous this error message is: what went wrong? (Apparently the search results expired. despite the flight number and date still being as unambiguous as ever but meh that’s the design they chose and it isn’t necessarily wrong just like they could have told me.)

                    Try what again? No matter how many times I hit “refresh” after it expires, it will give this same message. (Refreshing before it expires though will, in fact, update the information; that’s what I did last night.) So that doesn’t work.

                    Come back later? When? This particular flight is pretty rarely on time - half the time they’re early, half the time they’re late, sometimes very late or even cancelled. (My local airport is very small.) This information can be a bit time-sensitive, so it would be nice to know in this is anticipated to be temporary or longer term (if the website isn’t expected to come back, I might call somebody instead, or even just go to the airport early anyway just in case and check the monitors there.)

                    There’s a condescending attitude among some programmers that users are too ignorant to understand an error message anyway, so no point even trying. OK, maybe not everyone can find value in a stack trace, but you should still tell them something. Maybe not everyone will understand “Your search results expired” but even that alone at least gives a clue as to what might help: if the search expired, trying a new search might come to at least some of the user’s minds.

                    Or better yet you can say “Your search results expired, please start over.” (Which aa.com will do if you are looking at prices!)

                    Or better yet you can just automatically refresh the search results and not bother the user.

                    Now, sure, you might say this message is a bug. Someone should open a jira ticket to enhance the user flow with expired search results. Whatever, that’s their manager’s problem. But me, as a user right now, would much rather see even “ERR_EXPIRED_SEARCH” than “Flight Status: Something went wrong.” And like I hinted at earlier, if you really do think users are unable to read error messages, probably not a good idea to imply something went wrong with their sister’s flight when they’re nervously refreshing the page.

    2. 4

      Oh, wow, didn’t expect this post to show up here. Thank you for sharing it!