Originally Posted by
IceDane
However, the first place of ........ups still goes to OpenSLL, for the if statement with 0 as a condition, and a goto label inside it, to guard the code inside it from ever getting executed unless you jump into it.
What's wrong with it? It's a well known technique considering C has no exception handling. It's not just some cheap horror trick.
Sometimes you see things like this in C:
Code:
int func()
{
...
if(ptr_a == NULL) goto oops; // oops, go to exception handler
...
return 0; // normal return
oops:
// this handles an 'exception'
...
}
This is essentially a cheap form of exception handling. It's an easy way to keep the flow and logic behind what can go wrong clear to the programmer (goto's are probably most used for things of this nature today.)
There's a problem however, how do you do this in nested scope?
Code:
int func2()
{
if(ptr_a == NULL) {
/// ????
}
...
}
The problem is that at the point of ?????, if an 'exception' happens, you need to continue by eventually moving out of the scope of the if and returning to the normal program flow. But you can't just put a return at ??? followed by a block with your 'exception handler': the only way to get out of scope is to fall off the end, so where can you put your exception handler, without executing it, while getting out of the scope?
You model try, catch and finally:
Code:
int func3()
{
if(ptr_a != NULL) {
...
// try
if(ptr_b == NULL) goto oops;
if(0) {
oops:
// 'catch' block
}
// finally
...
}
}
The if(0) perfectly solves this problem of dealing with this problem inside nested scope (or out of it, for that matter,) and it lets you continue the normal program flow after the 'exception handling' has happened. It may seem awkward, but it's a decent representation of exception handlers in C when you need it. You could use macros to make it look nicer if you want:
Code:
#define THROW(x) goto x
#define CATCH if(0)
int func4()
{
if(a == 2) {
if(screwed) THROW(got_screwed);
...
CATCH { got_screwed:
...
}
...
}
..
}