Hacker News Reader

Comment by SlowRobotAhead | Hacker News Reader

> It’s like a goto statement, but it can even be used to jump outside of a function. It’s also a lot more difficult to read than a goto, since it looks like a regular function call.

Ah! Blood pressure rising!

> Like with goto, the common advice is to avoid

Whew. And then goes on to make a really good case for complicated task perform with simple error handling.

It’s a good application for not exactly general use cooperative routines but a specific use case of performing multiple procedural steps.

I think there it falls short and where an RTOS/OS will be more useful is when you have to wait on one of those steps.

I think that’s the harder example with the example of an HTTP request is waiting for the response and keeping that context ready and blocking in a separate thread. That ends up being easy to read and maintainable. But I suppose there is no reason you can’t do both.

View on HN

Does your blood pressure also rise from use of exceptions?

Because the pattern that emerges with setjmp/longjmp is pretty similar, and that's the most common use: to simulate what other languages offer with exceptions. The most prominent libraries I can think of that force you to do this are image related, libpng and libjpeg both use longjmp to handle errors [though IIRC it's optional in the latter].

Are there exceptions in C?

If I’m interviewing someone for a programming job and I see goto in there C code... they better have an amazing reason or they won’t be getting the job. Harsh, but it’s reality of how few people are suited for embedded programming.

Not sure what presence or absence of the goto has to do with embedded programming.

I spend a lot of time dicking with embedded C code. I think using goto is reasonable some cases. The classic case is to short circuit a block of code when there is an error of some sort.

   function(){
   
   // early returns here.

   // stuff
   // more stuff

   if(oops_err){
     goto some_error;
   }

   // yet more stuff

   // normal exit
   return 0;
   
   // bad exit
   some_error:

   // clean up

   return oops_err;
   }

The above is fine, you avoid a convoluted execution path. Or cleanup and a return in the middle of a function. Looking at the top of the function you see early returns. Looking at the end you see the normal and error exits.

This is specifically allowed in the Linux kernel coding style guidelines as well FWIW:

https://www.kernel.org/doc/html/v4.10/process/coding-style.h...

Not only is it fine, I think it's easier to reason about the control flow with this code than with languages that support exceptions like C++.

Standard C has no exceptions.

Goto is the typical way to handle errors without creating a hell mess of "hm, gotta close this file, free that buffer, blah blah" at every step where you might want to bail early. There are a few alternatives but none of them are better than goto and a few can be said to be worse.

While not being a prescribed way of doing things (deservedly) goto as well as some other "obsolete" tricks sometimes can actually make sense in low level C code especially on micro-controllers.

Denying potential job to a person on a basis of generic "goto is anathema" mantra is not a good idea until one looks at the code and understands what the "offensive" part is actually doing instead of using some code analyzer/text search blindly.

Using goto is standard for handling errors in C. It's used pervasively in the Linux kernel.

Reply on news.ycombinator.com