[ccan] help with gracefully dealing with alloc failure in a recursive function

[Rusty Russell]

On Fri, 7 Oct 2011 08:24:08 +1030, Daniel Burke <dan.p.burke at gmail.com> wrote:
> I'm wondering what a commonly acceptable method of handling this failure
> would be, my Google-Fu's not giving me answers I like, so   I'm turning to
> the collective wisdom of this list. I suspect my knowledge of other
> languages is poisoning my thought process.
> 
> So parsing XML in a recursive function, with a structure that contains the
> relevant state of the task. My initial plan is to add a variable to the
> structure named "failed", and if an alloc fails I set it, and then test this
> after every function call that can fail, trying to bail out to the head
> function ASAP, where I call the free function on the partial tree I've
> created so far.

It really depends.  There's a school of thought which suggests that you
shouldn't even try to handle it, just exit or crash.  After all, if you
are writing a library, that's what your users will do.  And testing it
is a pain (though, see ccan/failtest).

If you've decided to handle failure, then you have to decide whether you
expose it to the user.  If it's a simple case of returning NULL, you
probably should, but if it's going to make your API harder, I wouldn't
bother: remember that they won't handle it anyway.  One compromise I
increasingly like is a pluggable allocator: if they want to flag some
allocation failure, they can do it in their own allocator.

Finally, libraries like talloc make memory handling of complex
datastructures much simpler, to the point where you can often ignore
alloc failures lower down if you're not offering any guarantees that the
result is *usable* if allocs fail.

Hope that helps,
Rusty.