Wrap malloc in a function that push malloc'ed pointer on a global stack, insert NULL at the point where a try happens. When you throw an exception, simply free everything on the stack until the previous NULL. Problem solved.

Better yet, simply free memory at the exception throw site, if possible.

> Wrap malloc in a function that push malloc'ed pointer on a global stack, insert NULL at the point where a try happens. When you throw an exception, simply free everything on the stack until the previous NULL. Problem solved.

This frees everything, which isn't what you want. What if you've passed your pointer off to somewhere else where it's still in use?

> Better yet, simply free memory at the exception throw site, if possible.

Most of the time, your exceptions are coming from low levels, like IO libraries, that don't know anything about the memory that you've allocated.

> Most of the time, your exceptions are coming from low levels, like IO libraries, that don't know anything about the memory that you've allocated.

Yeah, but that's why you put exception handlers around anything that you expect to throw an exception, IO being a big one. Dealing with memory cleanup is definitely something that should be handled in the function allocating the memory.

So every function now needs a try/catch? Doesn't this kind of defeat the purpose?

Every call to a function that can throw an exception should have a try/catch block, so that things can be properly cleaned up. Global exception handlers are seldom useful outside of reporting the existence of an error for future usage.

Kind of defeat the point of exceptions in the first place. It becomes more like an "enhance error return value" thing.

The thing about an exception is that you can't do about it in a number of scopes. When you encounter the exception you just just jump to the scope where you can do something about it.

In that case, wouldn't it be simpler to explicitly check for error return on every call to such a function, and eliminate the need for an exception mechanism?

But every function can potentially throw an exception...

That makes more sense. I assumed he meant to free memory before throwing the exception.

Good point, but then again, control over memory is kind of the C killer feature, so you should know how memory flows around in your program.

If you use libraries that use internal malloc'ed memory, etc, you have to clean at the exception call site by calling the library cleanup function.

> This third one makes using longjmp for exceptions almost untenable in real life code.

No, it's pretty simple. Postgres does it with something called regions: your code essentially becomes transaction-based, where resources that need cleanup are put into a region associated with a try block, and all remaining resources at the end of the block's (successful or failed) execution are freed. It requires slightly more work than in C++, obviously, because you're not using C++.

This is nice. It's pretty much how the pool allocator "integration" works. I say integration in quotes because with the pool allocator you (also) have to be careful at the try site that any pools or subpools used in the code that could throw will be freed.