GnuTLS certificate verification vulnerability announced (CVE-2014-0092)

Re:GnuTLS certificate verification vulnerability announced (... by rkangel on Tuesday March 04, 2014 @06:20AM (#7339586)

What do other people think about the "goto" pattern for handling errors? I've never been a huge fan of it due to the unclear control flow you get, a point of view which this seems to back up very well. I'd much rather set a return/error code appropriately, encase each chunk of code in a 'if (OK == ec) {...}' and then clean up based on the ec at the bottom. That way what code is executed in any given circumstance is blindingly obvious and so is the clean up.

The "goto fail" pattern seems pretty common though - I was wondering what it had in its favour apart from being a easier to type (which would also be true of "not checking for errors" for example).

[ Parent | on HN ]

Re:GnuTLS certificate verification vulnerability announced (... by mpyne on Tuesday March 04, 2014 @03:28PM (#7342887)

It's actually not horrific IMHO in the context of C when you use it explicitly in this fashion, as a "poor man's exceptions with resource cleanup". And it's not simply a method to avoid typing, it helps with the very common design pattern of:

    acquire A
    acquire B
    acquire C
    
    do_work
    
    release C
    release B
    release A

It has all the benefit of "common return path" (since it is a common return path) without the 8 levels of indentation and random subsidiary conditional checks that obscure the code logic and add their own confusion. Instead you fail as fast as possible.

Like any other design pattern (C or otherwise) it's easy to misuse or abuse and it's not suited to every combination of library usage.

[ Parent | on HN ]