Elegant way for exiting a function neatly without using goto in C

Question

We often write some functions which have more than one exit point (that is, return in C). At the same time, when exiting the function, for some general works such as resource cleanup, we wish to implement them only once, rather than implementing them at every exit point. Typically, we may achieve our wish by using goto like the following:

void f()
{
    ...
    ...{..{... if(exit_cond) goto f_exit; }..}..
    ...
    f_exit:
    some general work such as cleanup
}

I think using goto here is acceptable, and I know many people agree on using goto here. Just out of curiosity, does there exist any elegant way for neatly exiting a function without using goto in C?

Answer 1

Why avoid goto?

The problem you want to solve is: How to make sure some common code always gets executed before the function returns to the caller? This is an issue for C programmers, since C does not provide any built in support for RAII.

As you already concede in your question body, goto is a perfectly acceptable solution. Never-the-less, there may be non-technical reasons to avoid using it:

• academic exercise
• coding standard compliance
• personal whim (which I think is what is motivating this question)

There are always more than one way to skin a cat, but elegance as a criteria is too subjective to provide a way to narrow to a single best alternative. You have to decide the best option for yourself.

Explicitly calling a cleanup function

If avoiding an explicit jump (e.g., goto or break) common cleanup code can be encapsulated within a function, and explicitly called at the point of early return.

int foo () {
    ...
    if (SOME_ERROR) {
        return foo_cleanup(SOME_ERROR_CODE, ...);
    }
    ...
}

_{(This is similar to another posted answer, that I only saw after I initially posted, but the form shown here can take advantage of sibling call optimizations.)}

Some people feel explicitness is more clear, and therefore more elegant. Others feel the need to pass cleanup arguments to the function to be a major detractor.

Add another layer of indirection.

Without changing the semantics of the user API, change its implementation into a wrapper composed of two parts. Part one performs the actual work of the function. Part two performs the cleanup necessary after part one is done. If each part is encapsulated within its own function, the wrapper function has a very clean implementation.

struct bar_stuff {...};

static int bar_work (struct bar_stuff *stuff) {
    ...
    if (SOME_ERROR) return SOME_ERROR_CODE;
    ...
}

int bar () {
    struct bar_stuff stuff = {};
    int r = bar_work(&stuff);
    return bar_cleanup(r, &stuff);
}

The "implicit" nature of the cleanup from the point of view of the function that performs the work may be viewed favorably by some. Some potential code bloat is also avoided by only calling the cleanup function from a single place. Some argue that "implicit" behaviors are "tricky", and therefore more difficult to understand and maintain.

Miscellaneous...

More esoteric solutions using setjmp()/longjmp() can be considered, but using them correctly can be difficult. There are open-source wrappers that implement try/catch exception handling style macros over them (for example, cexcept), but you have to change your coding style to use that style for error handling.

One could also consider implementing the function like a state machine. The function tracks progress through each state, an error causes the function to short circuit to the cleanup state. This style is usually reserved for particularly complex functions, or functions that need to be retried later and be able to pick up from where they left off.

Do as the Romans do.

If you need to comply to coding standards, then the best approach is to follow whatever technique is most prevalent in the existing code base. This applies to almost all aspects of making changes to an existing stable source code base. It would be considered disruptive to introduce a new coding style. You should seek approval from the powers that be if you feel a change would dramatically improve some aspect of the software. Otherwise, as "elegance" is subjective, arguing for the sake of "elegance" is not going to get you anywhere.

Answer 2

For example

void f()
{
    do
    {
         ...
         ...{..{... if(exit_cond) break; }..}..
         ...
    }  while ( 0 );

    some general work such as cleanup
}

Or you could use the following structure

while ( 1 )
{
   //...
}

The main advantage of the structural approach contrary to using goto statements is that it introduces a discipline in writing code.

I am sure and have enough experience that if a function has one goto statement then through some time it will have several goto statements.:)

Answer 3

I've seen a lot of solutions how to do this and they tend to be obscure, unreadable and ugly at some degree.

I personally think the least ugly way is this:

int func (void)
{
  if(some_error)
  {
    cleanup();
    return result;
  }

  ...

  if(some_other_error)
  {
    cleanup();
    return result;
  }

  ...

  cleanup();
  return result;
}

Yes, it uses two rows of code instead of one. So? It is clear, readable, maintainable. This is a perfect example of where you have to fight your knee-jerk reflexes against code repetition and use common sense. The cleanup function is written only once, all clean up code is centralized there.

Answer 4

I think the question is very interesting, but cannot be answered without being influenced by subjectivity because elegance is subjective. My ideas on it are as follows: In general, what you want to do in the scenario you describe, is to prevent control from passing through a series of statements along the execution path. Other languages would do this by raising an exception, which you would have to catch.

I had already written down neat hacks to do what you want to do with pretty much every control statement there is in C, sometimes in combination, but I think they are all just very obscure ways of expressing the idea of skipping to a special point. Instead I'll just make my point on how we arrive at a point where goto can be preferable : Once again, what you want to express using is that something has occurred that prevents following the regular execution path. Something that is not just a regular condition that can be handled by taking a different branch down the path, but something makes it impossible to use the path to the regular return point in a safe way in the current state. I think there are three options to proceed at that point:

1. return through a conditional clause
2. goto an error-label
3. every statement that could fail is inside a conditional statement, and regular execution is considered a series of conditional operations.

If your cleanup is similar enough on every possible emergency exit I would prefer the goto, because writing the code redundantly just clutters the function. I think you should trade the number of return points and replicated clean-up code that you create against the awkwardness of using a goto. Both solutions should be accepted as a personal choice of the programmer, unless there are severe reasons for not doing so, e.g. you agreed that all functions must have a single exit. However, the use of either should be consequent and consistent across the code. The third alternative is - imo - the less readable cousin of the goto, because, in the end you will skip to a set of cleanup routines - possibly enclosed by else-statements too, but it makes it much harder for humans to follow the regular flow of you program, due to the deep nesting of conditional statements.

tl;dr: I think choosing between conditional return and goto based on consequent style-decisions is the most elegant way, because it is the most expressive way to represent your ideas behind the code and clarity is elegance.

Answer 5

^{I guess that elegant may mean for you weird and that you simply want to avoid the goto keyword, so....}

You might consider using setjmp(3) and longjmp :

void foo() {
jmp_buf jb;
if (setjmp(jb) == 0) {
   some_stuff();
   //// etc...
   if (bad_thing() {
       longjmp(jb, 1);
   }
 };
};

I have no idea if it fits your elegance criteria. (I believe it is not very elegant, but this is only an opinion; however, there is no explicit goto).

However, the interesting thing is that longjmp is a non-local jump : You could have passed (indirectly) jb to some_stuff and have some other routine (e.g. called by some_stuff) do the longjmp. This may become unreadable code (so comment it wisely).

Even uglier than longjmp : use (on Linux) setcontext(3)

Read about continuations and exceptions (and the call/cc operation in Scheme).

And of course, the standard exit(3) is an elegant (and useful) way to go out of some function. You could sometimes play neat trick by also using atexit(3)

BTW, Linux kernel code uses quite often goto including in some code which is considered as elegant.

My point is : IMHO don't be fanatic against goto-s since there are cases where using (with care) it is in fact elegant.

Answer 6

I'm a fan of:

void foo(exp) 
{
    if(    ate_breakfast(exp)
        && tied_shoes(exp)
        && finished_homework(exp)
      )
    {
        good_to_go(exp);
    }
    else
    {
        fix_the_problems(exp);
    }
}

Where ate_breakfast, tied_shoes, and finished_homework take a pointer to exp that they work on, and return bools indicating a failure of that particular test.

It helps to remember that short circuit evaluation is at work here - Which may qualify as a code smell to some people, but like everybody else has been saying, elegance is somewhat subjective.

Answer 7

goto statement is never necessary, also it is easier to write code without using it.

Instead you can use a cleaner function and return.

if(exit_cond) {
    clean_the_mess();
    return;
}

Or you can break as Vlad mentioned above. But one drawback of that, if your loop has deeply nested structure break will only exit from innermost loop. For example:

While ( exp ) {
    for (exp; exp; exp) {
        for (exp; exp; exp) {
            if(exit_cond) {
                clean_the_mess();
                break;
            }
        }
    }
}

will only exit from inner for loop and doesn't abandon process.