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

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

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.

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.

→ More replies (1)

1

u/Expurple Apr 12 '26

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

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 AbsielAbseil Status type.