Hacker News Reader

Comment by xwdv | Hacker News Reader

Good error messages are hard. There’s so many things that can go wrong, and each needs its own custom explanation. Never really found a good way to organize this. And since errors should be uncommon, it feels like a waste of time coming up with thoughtful messages.

View on HN

The problem is that you have to know exactly what has gone wrong to show a proper message. But if you know what is wrong, most of the time the correct action is to fix the program so it does not go wrong instead of showing a better error.

With the main exception of user submitted data validations where it is up to the user to submit correct data. For the average web service, there the error is a stack trace and there is nothing the user can do so a blank screen with a "something went wrong, we have logged this erorr" is the only real option.

Even if there’s usually nothing the user can do I still like to have all the stack traces, etc visible - because sometimes there’s enough of a hint that you can get a workaround.

A number of DNS failures I’ve worked around with the hosts file.

You've worked around server-side DNS failures?

Yes - often the DNS issue is unrelated to the server itself - and sometimes a quick lookup shows an obvious cname error - or shows a round-robin dns where the response you have is failing but the others work.

Or if the host name has .eu.domain or something else indicating a geographic location changing that can get around a localized failure sometimes.

Good error messages have a template: a UUID, a description, and a suggested solution. This gives folks enough to try to solve it themselves and also enough to Google / grep with.

You can’t suggest a solution because if you were aware of the problem enough to suggest a solution you would just fix the problem. This 503 error from fastly was never meant to show to a user. You can’t do much to account for novel situations which shouldn’t ever happen.

A solution that the end-user can take. It's not unreasonable to ask user to check that their URL is correct for 404s, for instance. For 5xx errors, especially 502s and 503s, it's still helpful to tell users that there's nothing much they can do (apart from maybe monitoring the status page).

Without telling malicious actors how to break your systems further.

Reply on news.ycombinator.com