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?
Error handling style in C
31–40 of 45 posts
Re: Error handling style in C
#32Earlier 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.
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
#33Earlier 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.
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
#34There's the 5th method that I tend to use: if (!init_stuff(bar)) { return FALSE; } if (!do_the_thing(bar)) { return FALSE; } return TRUE;
that is how you handle errors in C.
Re: Error handling style in C
#35It 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,…
Re: Error handling style in C
#36http://vilimpoc.org/research/raii-in-c/
Despite the evil that can be made of GOTO, it has it's uses.
Re: Error handling style in C
#37http://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
#38Why 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...
Re: Error handling style in C
#39The site appears to be down. Does anyone have a mirror?