Re:Goto decorator for python
by haberman on Sunday March 11, 2012 @10:17PM
(#3692076)
"Obviously" goto is bad, but to quote one of Lua's designers, continuations are much worse, and yet it's considered "cool" to support continuations. It's programmer groupthink; one very smart person writes a famous article about how goto is bad and forevermore it's "obviously" bad. Goto is sometimes useful, and like lots of things it can be abused.
[ Parent
| on HN ]
I can't imagine a clearer way of treating errors in C than the macros from Zed Shaw, which use goto (http://c.learncodethehardway.org/book/learn-c-the-hard-waych...):
int test_check(char *file_name)
34 {
35 FILE *input = NULL;
36 char *block = NULL;
37
38 block = malloc(100);
39 check_mem(block); // should work
40
41 input = fopen(file_name,"r");
42 check(input, "Failed to open %s.", file_name);
43
44 free(block);
45 fclose(input);
46 return 0;
47
48 error:
49 if(block) free(block);
50 if(input) fclose(input);
51 return -1;
52 }Yes, the Linux kernel has used this error handling strategy for a long time (http://kerneltrap.org/node/553/2131). A variant on this is to have multiple error labels so that you uninitialize the correct set of things without the if statements (which may not be possible in cases where the resource is represented by an opaque handle).
And the reason the smart person decided Goto was bad has little relevance on programming today - he showed that Goto made it harder to prove, mathematically, that a program was correct.
When was the last time someone proved a program correct?
Several seconds ago I would assume. Just because real computer science doesn't get talked about much here doesn't mean that it doesn't exist.
As an addendum GOTO is still bad because it is much harder to parse (as a human reading the code) than using equivalent branching control statements. That was the whole point of Goto considered harmful, it's not mathematically needed so it's not syntactically needed either.