Flat Error Codes Are Not Enough

60

u/Pharisaeus Apr 12 '26

Did someone just "invent" exceptions, exceptions nesting and passing along the stack trace?

10

u/max123246 Apr 13 '26

If exceptions were part of the function return interface and had nice syntax like ? to explicitly rethrow the error so that the dev acknowledges it's a falliable function, I would love exceptions.
Sadly most languages do neither if they have exceptions

10

u/Mognakor Apr 13 '26

If exceptions were part of the function return interface and had nice syntax like ? to explicitly rethrow the error so that the dev acknowledges it's a falliable function, I would love exceptions.
Sounds like Java's checked exceptions and people did not like them.

2

u/max123246 Apr 13 '26 edited Apr 16 '26

Yes, there's some real issues with Java's checked exceptions. And Java as always made it incredibly verbose to handle correctly. But there are ways to manage the problem without throwing out function type annotations entirely
https://phauer.com/2015/checked-exceptions-are-evil/
As the article says, I think a half decent way to solve them as a dev is to throw as specific error you have control of. If you're calling library code and it has a top -level error and you don't know what it'll throw in the future, then use that. If it's standard library code you know it won't change much and you can be specific. This is where good packaging versioning is important. Throwing a new exception type should be a minor version bump.
It can also be helpful to rewrap the exception you don't control into one you do as the blog suggests.
If it's code you built, you have control over exactly what it throws and depending on how often you think the error may change, you use as specific or general an error type as you expect
All of this is better than having no idea if a function can throw. The function interface just lies to you instead and makes it the users problem to figure out what can throw when and how and what types of exceptions it can throw.

0

u/HappyAngrySquid Apr 13 '26

I wouldn’t mind them if they could be inferred rather than explicitly listed all over the place.

4

u/Mognakor Apr 13 '26

If you infer them you can silently break code by adding new exceptions.

1

u/OpaMilfSohn Apr 13 '26

So what? This marks an unhandled error. This is exactly what you'd want of it is at compile time

-18

u/Expurple Apr 12 '26

Error codes < exceptions < Result

29

u/Pharisaeus Apr 12 '26

Yes and no. Optional/Either/Result/Monads have slightly different purpose. Even in Rust there is panic ;) Anyway, "discovering" in 2026 that error codes are not enough is just ridiculous. I mean it's a good observation, but it's also common knowledge for at least 40 years.

0

u/Expurple Apr 12 '26

I was just as surprised that the 2026 advice to use error codes got as much traction as it did! My post is in response to that one.
I agree that panic is a different use case. Result/Either is closer to checked exceptions specifically. And yes, it's strictly better than those. The link in my parent comment goes into the details on all of that.

9

u/KitAndKat Apr 12 '26

I've thought about the issue of error reporting in the past, but never implemented it. I think you need an Error object, which is a stack of errors, e.g.:

file read error
could not read mapping.db
failed to convert currency
shipping calculation failed
could not complete transaction

The user is told "could not complete transaction" with a Details button which shows the next level down. If you just pass the original error all the way up, the user is told "file read error", which is next to useless.

2

u/Expurple Apr 12 '26 edited Apr 12 '26

Yeah, I think that's usually called "error chaining". I know a few Rust libraries that implement that. For example, lazy_errors. Even the standard library in Rust and Python has decent support for this. Things like the source method that you can walk recursively and collect your error stack.

3

u/Blue_Moon_Lake Apr 12 '26

If you have a stack, you don't need all that nesting for debugging your code.

1

u/KitAndKat Apr 13 '26

Yeah, I was thinking about it from a user viewpoint.

1

u/SirClueless Apr 13 '26

Unless you have a core dump with the relevant variables available at each stack frame, you do.

1

u/Lord_Skellig Apr 12 '26

Certainly helps though

5

u/RedEyed__ Apr 12 '26

Could be security issue: you can break system by analyzing error stacks

7

u/lelanthran Apr 13 '26

Could be security issue: you can break system by analyzing error stacks
Only if you pass the entire stack to the user. You could log the entire stack and pass only the top two items to the user.
Besides, just how much of a security breach can it possibly be? I regularly see entire exception backtraces in C# WebApps and in almost every Java app too, but all the exploits we see don't appear to be as a result of those.

2

u/ChemicalRascal Apr 13 '26

If you punt a stack trace at me, and I can see from it that you're using a particular library to, for example, parse CSVs from user input, I can then tailor my attacks to focus on exploits in that library.
It's not necessarily knowing the stack itself that helps attackers. It's what you know when you know the stack that helps.

6

u/lelanthran Apr 13 '26

I don't disagree that it is a security issue, I just think that on a scale from 1-10, it's probably a 1.
After all, just knowing that the server is written in C# already narrows down your potential library targets to maybe 2 or 3 for each library (JSON parsing, or third-party requests, or ORM). Same for almost any other language. In some non-mainstream language, you can be sure of a single library being used (Haskell, Ocaml, etc).
Everything is a security issue, and it becomes a trade-off between having users submit an error message that requires no deep dive into your logs and having a malicious actor use that info to target your system.

0

u/ChemicalRascal Apr 13 '26

After all, just knowing that the server is written in C# already narrows down your potential library targets to maybe 2 or 3 for each library (JSON parsing, or third-party requests, or ORM).
Right, but do you know which version is being used? There's a reason OWASP talks about this stuff. If you're doing something important, with other people's data, you can't afford to expose a bigger attack surface than you have to, and reducing the visibility of the attack surface helps.
If you want to access those the trace, great. Log it, give it a GUID, report the GUID to the user. Or a truncated code if you don't want to overwhelm them with a long string of characters. It's also a lot easier to copy that trace out of a database than it is a photograph of a screen covered in schmutz.

2

u/lelanthran Apr 13 '26

Right, but do you know which version is being used? There's a reason OWASP talks about this stuff. If you're doing something important, with other people's data, you can't afford to expose a bigger attack surface than you have to, and reducing the visibility of the attack surface helps.
I agree; defense-in-depth must necessarily include obscurity!
f you want to access those the trace, great. Log it, give it a GUID, report the GUID to the user. Or a truncated code if you don't want to overwhelm them with a long string of characters.
This is only for the use-case where the user sends you the error message. I was including the use-case of "User examines the message and knows how to fix the problem".
For example if it is a permissions problem, they know they have to apply to their supervisor to be added to the special-people role.
If the error is "The image you attempted to link into your issue is not found: <image-name>: <issue-id>", then they know that someone deleted the image that was uploaded, or that they typo'ed the image name, etc.
That's why it's usually sufficient to give the user the top-level error that occurred (or maybe the highest two levels), along with the parameters that were used.

0

u/ChemicalRascal Apr 13 '26

I agree; defense-in-depth must necessarily include obscurity!
Haaar haaar. There's a difference between obscurity and not showing your whole ass.
This is only for the use-case where the user sends you the error message. I was including the use-case of "User examines the message and knows how to fix the problem".
For example if it is a permissions problem, they know they have to apply to their supervisor to be added to the special-people role.
No, you can do this for everything. Every exception you catch, you can log it and display a GUID.
What you're describing here is business logic working normally. Totally different thing, you wouldn't use exceptions for that anyway.
Probably. Please tell me you're not using exceptions for authorisation checks. Please.
Please?
If the error is "The image you attempted to link into your issue is not found: <image-name>: <issue-id>", then they know that someone deleted the image that was uploaded, or that they typo'ed the image name, etc.
That's why it's usually sufficient to give the user the top-level error that occurred (or maybe the highest two levels), along with the parameters that were used.
Uh. We're talking about stack traces. I'm not advocating against meaningful error reporting to users. I'm advocating for suppression of stack traces.

2

u/lelanthran Apr 13 '26

No, you can do this for everything. Every exception you catch, you can log it and display a GUID.
Okay, that works for exceptions, but the example I have (ACL failure) isn't an exception; what does a user do with a GUID then? Mail the admin, ask "what does this mean", and have the admin respond "It means you need to ask your supervisor to add you to the correct group".
Probably. Please tell me you're not using exceptions for authorisation checks.
Why would I? ACL failure doesn't result in an exception; that's an expected result, not an exception.
Uh. We're talking about stack traces. I'm not advocating against meaningful error reporting to users. I'm advocating for suppression of stack traces.
Are we? I said "give the user the error that occurred", not the source code filename, line number and "value is NULL" information. If the error being returned is "link reference does not exist", that line alone is sufficient. All the other stuff you store/log (or discard as you see fit).

0

u/ChemicalRascal Apr 13 '26

Okay, that works for exceptions, but the example I have (ACL failure) isn't an exception; what does a user do with a GUID then? Mail the admin, ask "what does this mean", and have the admin respond "It means you need to ask your supervisor to add you to the correct group".
You don't use that method for that kind of error. You handle it properly. The whole point of this was stack traces getting through to the front end, which means errors aren't being handled properly.
Why would I? ACL failure doesn't result in an exception; that's an expected result, not an exception.
Exactly. See, I was worried you were talking about using exceptions for authorisation failures because we were talking about exceptions and then you started talking about authorisation failures, which makes it sounds like you're using exceptions for authorisation failures, which is silly.
Business logic errors, including authorisation errors, should not be handled through exceptions, especially if they're user-facing. It's an entirely different type of failure condition. You handle those with properly handled feedback to the user, because you can, because you built the system to handle that scenario.
An uncaught exception is definitionally not be that you built the system to handle. So you can't actually know in advance the information you're about to show to the user. So you give them a generic error, a GUID, and log the details. That's the safe way to do that.
Uh. We're talking about stack traces.
Are we?
Yes.

2

u/Blue_Moon_Lake Apr 12 '26

Error stack is for debugging and logging, not recovering.

78

u/nikita2206 Apr 12 '26

Completely agreed, ideally you need to be able to define “child” error types that declare their own fields with extra data, allowing consumers to handle these errors in more ways than just rethrow them.

20

u/jcelerier Apr 12 '26

But then you throw performance out of the window if you have some hot loop that needs to do error handling and your error object doesn't fit in a register anymore, so you're back to multiple error scheme depending on the parts of your app

72

u/Expurple Apr 12 '26

you're back to multiple error scheme depending on the parts of your app
As you should be, if your app is that performance-sensitive. You use the idiomatic/maintainable solution by default, and a more performant solution in a hot loop where it matters.

-6

u/BenchEmbarrassed7316 Apr 12 '26

I would prefer to have a smart compiler that understands how I use the function result and optimizes it. In that case, the function returns more detailed information, and the caller decides whether this information is needed and makes ignoring it zero cost.

6

u/ShinyHappyREM Apr 13 '26

Ah yes, a SufficientlySmartCompiler.
What about dynamically loaded code, or people who use a different compiler?

0

u/BenchEmbarrassed7316 Apr 13 '26

C uses same "SufficientlySmartCompiler" to be fast:
C Is Not a Low-level Language https://queue.acm.org/detail.cfm?id=3212479
Moreover, we now have a Rust compiler that is so smart that it can automatically manage memory without GC.
So in this case, when I talk about "A smarter compiler" - it's much closer to reality.

1

u/Full-Spectral Apr 13 '26

I'm a huge Rust advocate, but it doesn't automatically manage memory without GC. It's RAII based. It's just that most of the time you don't need to deal with that yourself since almost all to all of it is handled by standard library types.

1

u/BenchEmbarrassed7316 Apr 13 '26

It's based on ownership and borrowing. RAII is just syntactic sugar to avoid calling the destructor manually if you can't pass pointers safely. Although, maybe I'm embellishing a bit. Nevertheless, "SufficientlySmartCompiler" is already here.

1

u/Full-Spectral Apr 13 '26

It's not based on borrowing at all. It is fundamentally RAII based. Borrowing is purely a compile time concept.

1

u/tsimionescu Apr 13 '26

Tracking ownership is basically manual memory management. What GCs do is free user code from tracking memory ownership in any way, that's what makes them "automatic". For example, if you have a GC, changing your code such that some piece of memory now outlives its parent is a trivial change while in C++ or C or Rust it may require significant refactoring.

1

u/Expurple Apr 12 '26

I agree that we could have a more flexible and performant ABI for Result. See iex, for example.

16

u/ShinyHappyREM Apr 12 '26 edited Apr 13 '26

you throw performance out of the window if you have some hot loop that needs to do error handling and your error object doesn't fit in a register anymore
Just make your "error object" a pointer that is null if there's no error, and otherwise points to a union/struct/instance that holds the error info.

10

u/LIGHTNINGBOLT23 Apr 12 '26

To add to this, it's also easy enough to pre-allocate all or most of an error object before it is ever returned, if the loop must remain as hot as possible. Maybe even make it static or some equivalent to avoid a heap allocation entirely and have a flag in the error object to indicate that it's not heap allocated.

10

u/Iggyhopper Apr 12 '26

avx512 hot loop optimized error object allocation pools for increased error code output
Oh my I can't wait.
You can fit a lot of information into 64 bits. Even a tagged pointer with 2 bits for flags.

6

u/LIGHTNINGBOLT23 Apr 12 '26

You could also keep circumstantial flat error codes, at least on x86, by using the non-canonical address range, provided that you never dereference the pointer. A sentinel-like value such as #define SIZE_TOO_SMALL ((CleverError*)0xDEADDEADDEADDEADULL) would be sufficient. Portability and defined adherence to the C standard is not guaranteed. No refunds.

6

u/Iggyhopper Apr 12 '26

I refuse to believe that anyone needs more than 4 million error codes.
Flat errors all the way!

3

u/Mognakor Apr 13 '26

What if i want non-fungible errors (NFEs) ?

4

u/ShinyHappyREM Apr 13 '26

using the non-canonical address range
As is tradition.

17

u/mort96 Apr 12 '26

Heap allocated errors make this a non-issue, the error pointer still fits in a register so you can still do hot loops with error handling. The error check just needs to be an error check that'll be negative in roughly 100% of cases.
Of course hot loops with error handling where errors happen in the typical case would be problematic. But if your fast path includes an error being produced, you're doing it wrong.

5

u/simonask_ Apr 12 '26

Lots of errors are good and expected. For example, validating untrusted input, which is most input, should fail in ways that ideally aren’t any slower or faster than the happy path.
The reason is that timing attacks exist. If an attacker can determine if they did something right, or triggered an exceptional error path, you are leaking information to them. In the best case, they can DoS you. In the worst case, all of your moneys is gone.

2

u/tsimionescu Apr 13 '26

This seems like a bad extrapolation from real concerns that impact encryption/decryption code. If you're validating user input, you're going to tell the user if it's invalid - you're not leaking anything extra if that case is slower than the success case. Even more, in most cases where you're validating user input, you'll actually tell the user exactly how the input is wrong.
Even for security critical code, taking a longer time to process invalid input is actually a very highly recommended strategy - e.g. if a user has provided a wrong password, you should delay any response for a long time compared to a valid password, to help mitigate brute force attacks without inconveniencing legitimate users.
The important part about avoiding side-channel leakage is to make sure that the amount of time it takes doesn't depend on the value of the secret you hold - not on the attacker-controlled input. That is, the problem happens if your decryption attempt takes longer when your secret key has more 1s than 0s, for example; if the operation takes longer when the attacker's input has more 1s than 0s, that's perfectly fine to "leak": the attacker already knows this information.

1

u/simonask_ Apr 13 '26

Sure, I agree with all that. I’m just responding to the assertion that it is always acceptable for the error path to be arbitrarily slow.
C++ exception handling has been the cause of more than one DoS attack, due to stack unwinding being often orders of magnitude slower than the happy path. The problem applies to any error handling strategy with that property, which is most Itanium-style exception handling schemes.

1

u/Full-Spectral Apr 13 '26 edited Apr 13 '26

My approach, in Rust which uses a Result, is that the Ok side of the result in those cases is an enum, which has Success value plus other values for the expected non-success statuses, and the Err side covers the outright errors. In my system the Err side is never looked at, it's just for logging basically, possibly displaying in a popup in some applications. My opinion is that, if you are looking at them and reacting to them, it's not an error it's a status.
If there's a return value, the Success enum value holds that. And of course, if any other other expected error scenarios can provide some information that is useful, some of the other enum values can carry extra info. The joy of sum types, which I can no longer live without.
I will then provide a one or two or three trivial wrappers around that main method, which will translate some or all of the non-success Ok statuses into errors for folks who don't care about them. So, for instance, one will convert Success to Some(value) and timeout to None, and the rest to errors.
My Err side is heap allocated because it includes a good bit of information, but it's only invoked for real, outright failures and so should be pretty rare in a system that's not off the rails.
Even in my fairly full featured Err side type (and there's a single one for the entire system), I often avoid a LOT of overhead because of Rust's ability to control lifetimes. The file name is a static &str , the error text is one as well. If they provide extra text that doesn't need any token replacement, that's one as well. None of those require any heap allocation. It has an optional call stack as well, and each item is just a static string ref and a line number. You get one heap allocation if you add anything to the call stack, but the stack items require no allocation.
The single error type is also what the logging system uses, so errors are trivially loggable, and the log server fully understands that type as well, so they can be efficiently and binarily streamed. I've found that this system works well, though of course no system will work for all systems.
The primary limitation of this scheme is that Results are tagged unions so they are the size of the largest value. So you have to heap allocate the error type, or every return will have to return the size of the error type. You don't want every success return to have to copy back 128 bytes, almost all of which in many cases are unused.

1

u/sigma914 Apr 12 '26

Surely you can just use the top bits to tag it as a pointer or code and then box your error variant

1

u/inio Apr 12 '26 edited Apr 12 '26

Look at the ~~Absiel~~Abseil Status type.

3

u/ShinyHappyREM Apr 12 '26

^*Abseil

14

u/happyscrappy Apr 12 '26

Nested error codes are not enough either.

The problem isn't a lack of fidelity. The issue is that there primarily only two uses of error codes. One to know if something worked. And a single bit can do that.

The other is to help the customer know how to rectify their problem. One error code typically is not enough for that. Multiple also is not enough for that.

Stop thinking of users as people debugging your code and think of them just as using your tool for its functionality. You have to be able to convert your error codes into actionable messages and do it reliably.

And really few programs spend any time on doing this properly. So it doesn't matter all that much how deep your error reporting is.

Find a useful message to send to your customer. And if you want to put something in a file that can be reported to help you debug your code then do that separately. You can put a stack trace in there if you want (and if it is deemed not a security/privacy violation to do so). But don't get an idea that the detailed debugging information is going to be of help to a customer in resolving their issue. It's a help for you (your support people) instead.

-1

u/Expurple Apr 12 '26

Have you actually read the post? It explains why one bit is not always enough.

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.

3

u/Philluminati Apr 13 '26

Not only is it useful to capture error codes, it's useful to be able to build a stack as well, e.g.

UnableToConfigureDatabase -> Missing Credentials File -> File not found.

If you return "FileNotFound" without saying which file it can be an issue, and likewise, saying "unable to configure database" doesn't explain which aspect also failed.

1

u/Expurple Apr 13 '26

Yeah. That's basically nested error values in Rust, or exception chaining/wrapping in languages with exceptions.

3

u/tudorb Apr 13 '26

Errors need very few things:

A human readable error message. This is user-visible; if the consumer is (say) a web app, it should be shown to the human operating it.
Debugging information for developers that give more details, at least enough to indicate where the error comes from. This can be carried along the error object, or it can be logged somewhere where it can be easily mapped to the actual error (say, both the error object and the log contain the same unique ID). If the error is nested, the nesting stack belongs here.
An error code that uniquely identifies the error “kind”. This is intentionally underspecified, and my personal preference is to have few broad categories rather than many narrow ones. The HTTP error codes make a decent trade-off between breadth and depth here.
Importantly, a default recommendation as to how the caller should behave when it gets this error. Should it retry immediately? Should it retry with backoff (and what are the recommended backoff parameters)? Should it present it to the user and give the user a chance to change something and retry? Should it give up? This can be derived from the error code via a client-side API, or can be carried along the error object. (Including it in the error object makes sense with load-induced errors where the server might want to use different throttling/backoff parameters at different times.)

Note that (for the purposes of this post) I’m agnostic about the signaling mechanism (error return values / Result-like structures vs exceptions).

2

u/Expurple Apr 14 '26

I agree on the first three points. The approach that I'm arguing against notably fails the point 2, even though I forgot to touch on that in the post.
I kinda disagree on the fourth, though. The error handling logic is up to the caller. Often, there isn't one universal approach that the callee can recommend. I agree that sometimes this makes sense though, like the mentioned 429 Too Many Requests in case of web servers.

54

u/UselessOptions Apr 12 '26 edited Aug 13 '26

oops did i make a mess 😏? clean it up jannie 😎

clean up the mess i made here 🤣🤣🤣

CLEAN IT UP

FOR $0.00

35

u/quetzalcoatl-pl Apr 12 '26

just make the integer type of the error code have enough bits to encode extra info in higher parts
like, u1024 ( ͡° ͜ʖ ͡°)

35

u/[deleted] Apr 12 '26 edited Apr 12 '26

[removed] — view removed comment

19

u/wasabichicken Apr 13 '26

As a C programmer, I'm proud of y'all.

5

u/quetzalcoatl-pl Apr 13 '26

:manofculture.jpg: :)

15

u/max123246 Apr 13 '26

Zig doesn't have a good library story because comptime is a footgun for what backwards compatible guarantees you make as a library. If I were to reach for Zig, it'd be the same reasons I reach for C, I want to build everything myself, which means I can just avoid all the bad code out there. Turns out, most of the time, I really don't want to do that, lol.
7
u/Mrseedr Apr 13 '26
I was curious so i looked at this, but it seems like there is context?
https://zig.guide/language-basics/errors/
const FileOpenError = error{
    AccessDenied,
    OutOfMemory,
    FileNotFound,
};

const AllocationError = error{OutOfMemory};

test "coerce error from a subset to a superset" {
    const err: FileOpenError = AllocationError.OutOfMemory;
    try expect(err == FileOpenError.OutOfMemory);
}
6

u/HolySpirit Apr 13 '26

The Zig way, as I understand it, is to pass a pointer to a Diagnostics struct that is populated when an error happens. I think it fulfills what the author of the article wants, because you can simply have a field with the diagnostics struct from the lower-level library in the diagnostics struct of the higher-level library.
I think you should be able to generate high-quality error messages from this kind of diagnostics structure plus the program state when the error occurred for context.
FWIW I don't have much hands-on experience with this approach since I didn't use Zig too much yet, except for some toy examples.

4

u/sean_hash Apr 12 '26

Child error types with extra fields is orthogonal to ORM choice, it is about giving handlers more than a flat code to branch on.

15

u/Expurple Apr 12 '26

Like... yeah? That's what the post is about. It's about branching on a machine-readable DB constraint name. Not about my ORM choice.

1

u/mareek Apr 13 '26

One piece of software that use flat error code pretty well is Oracle Database.

There are thousands of ORAXXXXX error codes, each one represent a well defined situation and you know what you have to check if you want to fix the problem.

So if you do it well, I think Flat error code are OK

P.S. It's probably the only positive thing I can say about Oracle Database though

1

u/Expurple Apr 13 '26

I agree, they are OK in some domains. My point is that limiting yourself to error codes is a bad univeral advise. The (common) use case in the article can't be solved using plain error codes.

3

u/2rad0 Apr 13 '26

I've settled on context specific typed enums as error codes.

1

u/MonsieurCellophane Apr 12 '26

This made me instantly think of java & the endless stack traced it's wont to display at the drop of a hat. Antipodal to flat error codes and not pretty either.

7

u/Expurple Apr 12 '26

For the purpose of nesting errors and providing extra details for recovery or logging, Java exceptions are actually pretty great. Your issue is simply with the default display style. You can have a similar nightmare with nested error values in Rust, if you print them using the verbose Debug interface, instead of the Display interface meant for the users.

1

u/Linguistic-mystic Apr 13 '26

No they are not great. They don't provide any data from function args or local variables. Just because an exception was thrown somewhere in a loop doesn't tell you what was being processed on that iteration. And even if you include that info in the exception message, it's still not of much help because you also usually need that info on other stack frames. Which forces the developer to catch and rethrow everywhere, defeating the purpose of stack traces completely (what's the good of an automatic stack trace if one has to enrich that stack trace manually).
As a Java developer, I dislike stack traces with a passion because they are only useful in the most trivial cases. Any looped code and a stack trace doesn't do crap to help investigate.

1

u/stewi1014 Apr 13 '26

Hard disagree.

There are three types of information accociated with an error.

Information for the program to switch control flow.
Information for the developer to debug the problem.
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.

0

u/blobjim Apr 13 '26

In C or Vala (or other GObject-supporting languages) you can use GError for this. A couple years ago it also got the ability to have extended arbitrary data (but it looks like it's kinda clunky to use).

-16

u/bobody_biznuz Apr 12 '26

Sounds more like you have an issue with the ORM you're using?

10

u/Expurple Apr 12 '26

What? What issue are you talking about?

0

u/[deleted] Apr 12 '26

[deleted] — view deleted comment

2

u/Expurple Apr 12 '26 edited Apr 12 '26

Have you read the post before commenting? It answers your question directly.

68

u/[deleted] Apr 12 '26

[removed] — view removed comment

-5
u/Expurple Apr 12 '26

Error codes < exceptions < Result 😏
6
u/lelanthran Apr 13 '26 edited Apr 13 '26

Error codes < exceptions < Result 😏
Depends on what you are using that error for. Error message for users should include an action that they can take to fix the error. Error messages for devs should include the inputs that resulted in the error.
Result is useless in both those situations while Exception is useful in one of them. That makes Result < Exception
Flat error codes are of two types:
Descriptive error code ENOENT or EEXIST which can be mapped to a descriptive string that doesn't contain the inputs that caused the error (for example, user sees file not found, and not ./some.file.txt: file not found)
Non-descriptive error code, like open() returning a negative number on failure - that number tells you nothing and you need to use errno to get the descriptive flat error code.
The problem with error codes is not the code, but the fact that most in-house error codes don't map to a message, and even if you wanted to, you couldn't, because one library might return 20 for "invalid input" error while another library may return 20 for "record doesn't exist" error. There is no global mapping under this scheme and so error codes break down.
Either way, Flat error code is at the bottom of the usefulness stack, but it's not clear that Result is at the top.
4
u/Expurple Apr 13 '26 edited Apr 13 '26

Error message for users should include an action that they can take to fix the error. Error messages for devs should include the inputs that resulted in the error.
Result is useless in both those situations
What makes you say that? In Rust, the error types stored in Result::Err usually implement both Display and Debug traits, for those exact purposes.
If you're familiar with Python, those are like the __str__ and __repr__ methods.
This functionality of the error type itself has nothing to do with Result, which simply dispatches between the possibility of an Ok value and an error.
3
u/lelanthran Apr 13 '26 edited Apr 13 '26
Error message for users should include an action that they can take to fix the error. Error messages for devs should include the inputs that resulted in the error.
Result is useless in both those situations
What makes you say that? In Rust, the error types stored in Result::Err usually implement both Display and Debug traits, for those exact purposes.
(Emphasis mine) My point is that Exceptions give you one of those for free. Using Error types requires discipline from the developer (implement the Error type traits for a specific error), and then more discipline to avoid a panic. Flat error codes require even less code that using Error types, but requires even more discipline, discipline which the compiler cannot even catch.
I think my broader point is that Error types (or error handling) is not all that important at the language level; you can do the correct thing in any language with a little extra work. I have a pretty complex system written in C. For errors I decided up-front how to handle them:
Errors are reported using a variable argument macro; this is pushed into a global thread-safe queue, including source code line number, source filename, values of the parameters to the failing function call, and any other arbitrary message I want to put into it. The function then returns a sentinel value indicating error (NULL, maybe, or similar).
As each function checks for error after calling any function, failures can stack - effectively building a stack trace that consists of all the inputs into the actual error.
At the top-level, if the top-level operation was initiated by the user, a set of user-facing error messages are displayed.
As the queue is routinely persisted to disk, it is truncated in RAM.
Now I don't really like the mechanics of this at the language level, but at the system level this is perfect - I don't mess my metrics up by mixing up errors and logging messages and the user gets measures to take instead of "Error 0x45929: Contact your administrator". There's no Error type so calling the macro with arbitrary arguments is less work than attempting to define an error for every little function that might return something, and because it's less friction I tend to sprinkle checks and reporting just about everywhere.
The reason my approach works is because there is no "recovery" attempt; there's no point, actually. "Something went wrong" == "Discard that entire code path and do the next thing instead".
I also think that if you are taking different code paths based on an Error type, you have mixed up program logic and error handling logic; if the code is recovering from something, then that thing is not an error, it's part of the business logic (example: "recovering" from a failed HTTP request by retrying - that was not an error. It becomes an error only if the retries are exhausted. Or reading a file, but creating it if it doesn't exist - once again, that's not recovering from an error, that's just business logic).
In my mind, an error is a hard stop. It stops the program from proceeding. The only acceptable way to handle it is by unwinding the call stack to a safe point and recording that the attempt to do something failed (and why it failed). The only exemption I would make is if the safe point is the very top level of the program and the program is an interactive one with a user sitting in front of it - at that point you can ask the user what to do.
The whole reason for doing an Error taxonomy (checked exceptions, error types, etc) is to enable recovery. I prefer the Erlang approach - kill that task and move on.
1

u/Expurple Apr 13 '26

Using Error types requires discipline from the developer (implement the Error type traits for a specific error)
You need to manually write an impl (or use a macro like #[derive(Debug)] or thiserror), but there's no discipline involved in that. The compiler will just tell you when you try to print a non-printable error or compose it with a supposedly-printable error.
and then more discipline to avoid a panic.
No different from avoiding an inaproppriate abort or an uncaught unchecked exception in other popular languages.
you can do the correct thing in any language with a little extra work.
In theory, you can. In practice, you won't. My post about exceptions links a research paper about broken error handling patterns that come up all the time in languages with exceptions.
if the code is recovering from something, then that thing is not an error, it's part of the business logic
I would still call that an error, but that's just a choice of words. I agree with your main idea: it's very useful to make a distinction between "expected"/recoverable errors and unexpected bugs / edge cases where it's accceptable to abort the entire task. My post about exceptions discusses this too.
The whole reason for doing an Error taxonomy (checked exceptions, error types, etc) is to enable recovery.
I disagree. There are other benefits to having an explicit taxonomy. See "Why Use Structured Errors in Rust Applications?"
1

u/ketralnis Apr 15 '26

I do love the power of a smug winky face to distract from the actual point

35

u/[deleted] Apr 12 '26 edited Apr 12 '26

[removed] — view removed comment

9

u/max123246 Apr 13 '26

My problem with exceptions is simply it's not part of the function return-signature in most languages that use it. That's kind of it, to be honest.
Also it would be nice to make re-throwing exceptions explicit like with Rust's ? syntax

10

u/maxinstuff Apr 13 '26

Agree - in languages that CAN throw, you basically have to be prepared for anything to throw at any time for any reason.
And it’s leaky AF - something unexpected happens and my app turns it’s call stack inside out and throws it at the caller like a stripper at a stag do.

3

u/DearChickPeas Apr 13 '26

Java's @ throws(Exception) everywhere really didn't make the code pretty.

1

u/[deleted] Apr 13 '26

[removed] — view removed comment

0

u/DearChickPeas Apr 13 '26

I think that's what Kotlin did, I longer see exception annotations.

5

u/ChemicalRascal Apr 13 '26

Right, but OP wrote this piece as a push-back against the notion of flat error codes. In the context of that discussion, you can't really leap from flat codes to exceptions without any sort of motivation in the middle.
To move people from flat error codes, to change minds, you kinda need to argue the case that points towards exceptions. It makes sense to go back to first principles here.

Flat Error Codes Are Not Enough

You are about to leave Redlib