From: Archie Cobbs (archie@whistle.com)
Date: Wed Sep 09 1998 - 21:20:01 EDT
Godmar Back writes:
> I suggest we ensure that all methods invoked by the verifier
> fail instead of throwing exceptions. It is the caller's responsibility
> to ensure that the failure is recognized and that an exception is
> thrown when it is safe to do so.
>
> ...
>
> Another alternative, which would work with Tim's idea of keeping track
> of locks and unlocking them if necessary, is to require all code to be
> able to deal with exceptions. That would mean that all code would have
> to be reentrant. Currently, this is not the case.
This is an interesting problem. I agree with Godmar, ie, in using
error return values and having all callers check the error return.
This also implies that any function that discovers an error in the
middle of execution must manually "clean up" after itself before
returning that error (ie, releasing any locks held, tidyClass() or
whatever).
IMHO, trying to do try/catch/finally type stuff in C is noble,
but in doing it the programmer still has to keep conscious that it's
done *right*, or else it doesn't work. Macros can help this, etc.,
but it's all kindof painful and everyone has to understand many
subtleties. I would love for someone to prove me wrong, however.
Treating a function call like a "black box" that either returns OK
or FAIL, leaving the world in a consistent state either way, is a
well understood, old familiar paradigm.
In doing this, I end up writing a lot of code that looks like this..
func()
{
if (step one fails) {
goto fail1;
}
if (step two fails) {
goto fail2;
}
if (step three fails) {
goto fail3;
}
return OK; /* done */
fail3:
undo step two
fail2:
undo step one
fail1:
return FAIL;
}
It may be ugly, but at least it's clear what's going on.. :-)
Another point is performance: assuming the common case is func()
returns OK, then the old familiar way has minimal overhead, while
the try/catch stuff pays the price every time.
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:56 EDT