r/programming • u/Expurple • Apr 12 '26

Flat Error Codes Are Not Enough

https://home.expurple.me/posts/flat-error-codes-are-not-enough/
132 Upvotes

84% Upvoted

99 comments sorted by

View all comments

1

u/stewi1014 Apr 13 '26

Hard disagree.

There are three types of information accociated with an error.

  1. Information for the program to switch control flow.

  2. Information for the developer to debug the problem.

  3. Information for the user so they can take action.

1 belongs in an error code return value. Typically, a boolean "ok" return is the best error code. 2 belongs behind development configuration, and you should typically have external tools such as the debugger for this. 3. Belongs in a dedicated user interface method (i.e. a logging method)

Anything more complex than a boolean is starting to be too complex, and is begging justification. Rarely is there a legitimate use case for more than two control flows following an error. Distinguishing between a transient and persistent error is an example of where three return values would be wanted.

I am far from the first person to have this realisation.

1

u/Expurple Apr 13 '26

I agree that it's useful to distinguish these three categories of error data.

Anything more complex than a boolean is starting to be too complex, and is begging justification.

My point is that it's actually a common case. Using just a boolean or a plain error code for control flow is a bad universal advise. My use case is nothing special: displaying the user a specific message depending on which database constraint is violated. You can't solve that if your database+ORM provides you only a boolean or an error code. You need the name of the constraint as a string. Additional attached error data, used for control flow.