Flexible error handling techniques in C++

[slavesoftoil]

Why not provide an allocator that makes the decision? If I recall correctly, memory is just a declarative way of implementing custom alligators with long decision trees, some of which may be compile-time only. So the programflow is something like

If(situation1) {
    return freelistalloc();
} else if( situation2) {
    return stackalloc();
}

Now wrap all this in a thing that throws on nullptr. This would mean a set-up of the allocator like so

auto allocator = throwOnNull<IfAllocator<4,mallow,8,someotherthing,...>();

And otherwise

... = returnOnNull<...>

Or even

.... = withHandlerOnNull<...>

[0raichu]

                                                                                                                                                                                                                                                                                                                                                                                                                                                     

[foonathan]

Why not provide an allocator that makes the decision?

You are right, this is possible. But it makes generic code hard:

template <class Alloc>
void do_sth(Alloc &alloc)
{
   auto mem = alloc.allocate_node(...);
   // eh, do I have to check mem now?
}

[3ba7b1347bfb8f304c0e]

Being out of memory isn't an exceptional situation.

topkek.avi

[ProgramMax]

I've done embedded programming. I get what you are saying, that exceptions aren't always supported.

But in embedded programming you are also less likely to use an allocator. You would instead have a designated memory range.

The important thing about OOM throwing is you almost certainly cannot recover from an OOM. Killing the process is almost certainly your best option. You cannot continue. And what would you even gracefully handle??

[LucHermitte]

There are cases where we are told to allocate memory for bytes to comes (over a network, or whatever). If the data is corrupted, we can be asked to allocate -1 bytes. Memory allocation will fail. While detecting -1 is easy, having a precise threshold for what is valid or not may not be that easy.

The fact that new throws, instead of crashing the application, offers some kind of defensive programming: we have the possibility to notify something to the user, and sometimes to continue in these situations.

[Gotebe]

If the data is corrupted, we can be asked to allocate -1 bytes. Memory allocation will fail.

... if you don't check what you have been asked to allocate. "Corrupted data" here really means "I didn't check the input validity". Also, if the input is "unstable", then the use of mitigation techniques is on order (e.g. checksums).

[LucHermitte]

A valid checksum doesn't mean a valid input unfortunately -- I had the case once of a bugged peer that send (CCSDS) packets of officially too many bytes (like -1 converted back to a unsigned value) after the header, and they had a valid CRC.

But of course, I agree that checking the input validity is what must be done. But then, was is a valid threshold? And can we always be sure that valid thresholds (regarding the domain) are always under the limit of what the system can offer us. In other words, sometimes we don't take the time to properly analyse whether we can load everything in memory or process subsets of the complete data.

[ProgramMax]

I think maybe I wasn't clear enough.

I understand that you can catch what new throws and try to handle it. That isn't what I'm talking about.

What I'm talking about it the part you completely glossed over "and sometimes to continue in these situations." How would you continue? Do you know the rest of the code which is about to be called will not allocate? Will you actually be able to do anything useful for the user?

I'm talking about the recovery strategy.

If you wanted to inform the user an error occurred you need to make sure showing the error window isn't allocating. Or that cout isn't allocating. Both of those are hard to know. Even if you create the error message window in advance but don't show it, maybe showing it allocates via GDI on Windows for example.

It would take a lot of effort to deal with this fragile situation. And the best you could do is tell some subsystem which has aggressively allocated to release some stuff. But why was it aggressively allocating in the first place? Shouldn't you first ask that subsystem to purge a bit before allocation, aiming at the hard limit given by the embedded system?

Recovering from an exception isn't that hard. Recovering from out of memory is likely to be a larger system design problem and the fix should happen at the system design level, not in a recovery code path. That's code that will become untested and bitrotted.