In C I just used goto - you put a cleanup section at the bottom of your code and your error handling just jumps to it.
#define RETURN(x) result=x;goto CLEANUP
void myfunc() {
int result=0;
if (commserror()) {
RETURN(0);
}
.....
/* On success */
RETURN(1);
CLEANUP:
if (myStruct) { free(myStruct); }
...
return result
}
> The advantage being that you never have to remember which things are to be freed at which particular error state.
You also don't have to remember this when using defer. That's the point of defer - fire and forget.
One small nitpick: you don't need check before `free` call, using `free(NULL)` is fine.
You're right that it's not needed in my example but sometimes the thing that you're freeing has pointers inside it which themselves have to be freed first and in that case you need the if.
There are several other issues I haven't shown like what happens if you need to free something only when the return code is "FALSE" indicating that something failed.
This is not as nice as defer but up till now it was a comparatively nice way to deal with those functions which were really large and complicated and had many exit points.
If you have something which contains pointers, you should have a destructor function for it, which itself should check if the pointer is not NULL before attempting to free any fields.
We are talking about C. A destructor function in C is a function that gets called when the library gets unloaded. No you shouldn't have a destructor function for it.
The C language has no such concept of attribute destructor and I am not talking about attribute destructor.
I just mean, in the simple English sense, a function which exists to deallocate a structure.
That's certainly one way to do it if you're writing all the code.
If you have something which doesn't come with such a function, nothing stops you writing it?
But it does keep one in the habit of using NULL checks.
It is pointless, because in Linux all you get is a virtual address. Physical backing is only allocated on first use.
In other words, the first time you access a "freshly allocated" non-null pointer you may get a page fault due to insufficient physical memory.
By default, yes. You can configure it to not overcommit
Right, but as a programmer you rarely have control over that. And even if you do, you often can't handle out of memory errors gracefully.
Thus, for a typical situation it is reasonable to log the error and bail out, rather than adding extra custom error handling around every single memory allocation, which ends up being code that is never tested.
defer is a stack, scope local and allows cleanup code to be optically close to initialization code.
The disadvantage is that a "goto fail" can easily happen with this approach. And it actually had happened in the wild.
This looks like a recipe for disaster when you'll free something in the return path that shouldn't be freed because it's part of the function's result, or forget to free something in a success path. Just write
if you meant At least then you'll be able to follow the control flow without remembering what the magic macro does.In your cleanup method you have to take the same care of parameters that you are putting results into as any other way you can deal with this. All it does is save you from repeating such logic at all the exit points.
But you have to give this cleanup jump label a different name for every function.
You don't. Labels are local to functions in C.