From: Tim Wilkinson (tim@transvirtual.com)
Date: Wed Sep 09 1998 - 23:00:55 EDT
I'm pretty much in favour of tidying up these C exceptions and replacing them
with common-old-garden error returns - was good enough for my father and his
grandfather before him :)
Cheers
Tim
Archie Cobbs wrote:
> 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
-- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:56 EDT