meeting log January 30, 2001

Derek Atkins warlord@MIT.EDU
02 Feb 2001 14:40:55 -0500

Except you still need to check error status/return values anyways.
Consider that if you throw an exception, you may not have appropriate
state to continue processing.  This implies that you must stop
processing and reverse up the stack until the exception is handled.

Take for instance a code snippet that looks like this:

	TRY {
		read_packet(packet, port);

So, what happens if read_packet throws an exception?  It means you
CANNOT continue to parse_packet, because packet would contain invalid

So, you still have to check for error conditions at every function
call that is expected to throw an exception.

-derek writes:

> It's been rumoured that Tyson Dowd said:
> > 
> > Exceptions also involve more complicated control transfer.  Consider:
> Yes, you're right, I should be more careful. I have to rephrase to say
> that an error stack solves an interesting subset of the problem that
> should be sufficeint for our needs.  Doing the setjmp() implementation
> scares me: the implementation is prone to subtleties of behaviour, and
> it also makes using gdb and other debuggin hard, and finally, it
> potentially makes our code more complex and harder to read.   And the
> reason I like the error stack is that it makes code easier to read: 
> no more checking return values on each and every function, & trying to
> deal with super-extremely unlikely errors over & over again, all
> through the code.
> --linas
> _______________________________________________
> gnucash-devel mailing list

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available