Once again I’m working a lot with error handling. This seems to be pretty common, whenever I start helping out on a new project. It seems that a lot of projects do error handling sub-optimally.

The code I’m working on is no exception. And one of the mistakes it makes I’ve seen on practically every other project: Conflating user errors and application errors.

I think most developers have a pretty good idea that when software does something it shouldn’t do, that’s an error. And we should log errors, right? Because somebody probably cares about fixing that error!

But here’s the thing: Not all errors are created equal.

For most server applications, there are two broad categories of errors (non-exhaustive; some applications have othres):

• Errors for end users of the software
• Errors for developers/administrators of the software system

When all errors are treated the same, this distinction is lost, and we end up sending clients errors like:

No user can possibly take advantage of a stack trace, or details of a syntax error.

On the other side, you end up with a server logs with details of malformed JSON input, and a user error that says nothing more than “Bad Request.”

When handling errors, consider: Which human can act to solve this? Then behave accordingly.

• For user-generated errors, send them all the relevant info, and don’t inform your developers
• For application errors, which need attention from a developer (because it’s a likely bug), don’t send details to the user, but do send details to your devs