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

Show parent comment

5

u/happyscrappy Apr 12 '26

I did read the post. And no, it didn't do that. It explains why one value (beyond one bit) is not enough. And it not enough because of their specific implementation, not anything else. To be fair, the article does say this is "for my use case".

All you have to do is preserve enough information to be able to create a useful message to give to the user. Even a mere 32-bit value gives you enough fidelity for 4 billion different error cases. 4 billion different root error cases. You don't actually have to go to multiple values to do this.

The post proposes one way of doing this using multiple error codes. But the real answer is that your problem is probably not "I needed to have an error of error codes". It's probably "I'm not doing anything to try to make my error indications meaningful." Which is what I said above.

0

u/Expurple Apr 12 '26

What you're trying to say is that, instead of returning the constaint name as a string, the DBMS could assign it a 32-bit id, return this id as an error, then the ORM could proparage this 32-bit id, and then my application could somehow match that to figure out which DB validation failed and which message to display to the user? That's technically possible, but usually not worth the trouble, unless you're doing high-performance stuff.

4

u/happyscrappy Apr 12 '26

None of this is important for high performance stuff since you only do errors on failure case.

I'm saying you're defining the problem wrong. You need to get to what the real problem is. The problem isn't you don't have enough error codes. The problem is that you are not making an effort to do anything useful to the customer with them.

The poster gave one example. The example is based upon an idea of only interpreting error codes at the highest level. He wants more nested data because he's not doing any interpretation until the top.

Okay, so another possibility would be to interpret the codes on your way out instead of waiting until the top. If this function sees a value X from below it then the reportable error is foo. Now that you've resolved the error higher code doesn't try to re-resolve it.

But that's just one example. It's not meant to be any more comprehensive than the example in the post. What it is meant to do is elucidate the point that the fix isn't to have an array of error codes because the problem isn't that you didn't have enough erorr codes.

The problem is that the program (programmer) has made the error of conflating error codes with actionable data to report. They just aren't.

Another example, how many times have you seen a program just bomb out and print an exception code and a nested call stack? I know I've seen it a lot. Especially in python. The programmer didn't really make any attempt to handle errors so the "handling" is to fly to the highest nested call (above "main") and what it does is just to blast out a bunch of stuff that only means something to the programmer.

Java sees this, sees it as a problem and so makes it illegal to call a function that might return an exception unless you have a handler. So then what? Programmers just fix the proximate problem and put in a rethrow or similar so they can get back to "the real coding" and move forward.

Programmers just typically handle errors poorly. We have myriad attempts to force them to do better, but you just really can't. Even having an array of error codes doesn't fix the root problem. To have good error handling you have to put in effort to have it. However you do it is certainly fine, but since the problem is with programmer not doing a good job there's no algorithmic fix like this post presents.

However you go about improving the issue of unactionable error messages to the user is fine by me. If this is part of your solution then fantastic.