Live data from Hacker News

Error handling style in C

pixelstech.net

31–40 of 45 posts

Re: Error handling style in C

#31

a related question--how do people generally build up decorated strerror messages? e.g. in some versions of ls, "ls foo" (when foo doesn't exist) will print "ls: stat: foo: No such file or directory". how is that string built up?

Look at the man page for err(3) and related functions.

Re: Error handling style in C

#32
post #14
post #10

Earlier quoted context omitted.

In general, gotos are bad. For error handling in C, they're perfect. Just don't jump backwards in code.

Jumping backwards is fine, too. It's okay to ignore Dijkstra when he is wrong.

Dijkstra justified his paper against gotos with reasoned statements that make a lot of sense.

Unstructured goto's that do not form simple loops or skips are going to make the position in code a much more complicated notion. And the position in code is crucial to understanding the meaning of variables, for example.

Re: Error handling style in C

#33
post #18

Earlier quoted context omitted.

I guess it's fine to use multiple targets too. However, usually you can get away with one, because free(NULL) and similar cleanups tend to be no-ops. So you have something like: char *foo = 0, *bar = 0; if((foo = malloc(X)) == NULL || (bar = malloc(Y)) == NULL) goto cleanup; make_me_millions(foo, bar); cleanup: free(bar); free(foo); In this case, and many cases like it, there's no need to have two jump targets, becau…

because free(NULL) and similar cleanups tend to be no-ops. So you have something like You really need to check the specification on each function. free is defined that free(NULL) is no-op, but there are other things where that is not the case. Also, that code is not portable since NULL does not have to be 0.

> You really need to check the specification on each function.

Sure, but I need to do that anyway and constantly, since I use far too many API's to memorize. It's also convenient to make cleanup(NULL) a no-op for the API's you create.

NULL is zero. Even if the standard would allow it to be something else, it's not relevant with the compilers and platforms I use. There's no point in being a language lawyer just to achieve "portability" to some imaginary platform where a byte is 7 bits and NULL == 0xdeadbeef. Make a list of compilers and platforms you support and forget the rest if you want to get stuff done.

Re: Error handling style in C

#34
post #6

There's the 5th method that I tend to use: if (!init_stuff(bar)) { return FALSE; } if (!do_the_thing(bar)) { return FALSE; } return TRUE;

this is correct and why the original post is all wrong. what is calling foo()? it should be making sure foo() is happy, and if not, then continue your logic from there.

that is how you handle errors in C.

Re: Error handling style in C

#35
post #3

It lacks 4th method that I find the best: with long jumps. I mean for example: jmp_buf errbuf; int result; if( !( result = set_jmp ) ) { /* Code to do on fail. Result may be some error code */ } else { someaction( par1, par2, ..., errbuf); anotheraction( par1, par2, ..., errbuf); /* Etc. */ } errbuf might be global if you prefer, but I'd rather avoid them. When something is wrong called function calls longjmp(errbuf,…

Unfortunately longjmp() is not available in the Linux kernel, so I integrated the BSD implementation of it into my library/kmodule for this purpose: https://github.com/haberman/upb/blob/master/bindings/linux/s...

Re: Error handling style in C

#37
Here's the error handling I teach for C:

http://c.learncodethehardway.org/book/learn-c-the-hard-waych...

It's using the gotos, but I make macros that hide the actual word "goto" away so that idiots (who think goto is bad because of a ranting "paper" written decades past) will not notice it.

That and I print out error diagnostics, the location of the error at the time, and the errno. These macros probably saved me a good decade of time finding errors in C.

Re: Error handling style in C

#38
post #5

Why goto is bad? Again this "structured programming" bullshit. Kernel uses 2 a lot to handle errors like here [1]. [1] https://github.com/torvalds/linux/blob/master/mm/shmem.c#L99...

Just because linux kernel use goto's doesn't mean that goto isn't bad. We need another argumentation.

Re: Error handling style in C

#40
post #14
post #10

Earlier quoted context omitted.

In general, gotos are bad. For error handling in C, they're perfect. Just don't jump backwards in code.

Jumping backwards is fine, too. It's okay to ignore Dijkstra when he is wrong.

C already has a command to jump backwards in a loop. Continue.
Post reply on HN