meeting log January 30, 2001

[linas@linas.org]

It's been rumoured that Derek Atkins said:
> 
> Except you still need to check error status/return values anyways.

(1) only if you want to.
(2) an error stack does not prevent you from doing this; its just
    frequently simpler.

> Take for instance a code snippet that looks like this:
> 
> 
> 	TRY {
> 		read_packet(packet, port);
> 		parse_packet(packet);
> 	}
> 	CATCH {
> 	read_error:
> 		close_port(port);
> 	}
> 
> So, what happens if read_packet throws an exception?  It means you
> CANNOT continue to parse_packet, because packet would contain invalid
> data.

There are two ways that this is dealt with.  
(a) with true try-catch semantics, one *never* returns to to where one
    left off. The longjump is 'permanent', you don't return back to
    resume where you left off.   One hops out of the middle of
    read_packet, and goes to CATCH, and that's it. (That's why they call
    it 'jump': its a goto, not a call.)

(b) With basic error-code-less void-return-value heuristics:
    If read_packet() got an error, it sets packet=NULL.  And then
    parse_packet checks for NULL==packet, and returns instantly 
    without any complaints (without generating any further errors) 
    if it is.   Basically, you fall through the try block bacuse the 
    rest of it behaves as a no-op.

Defacto, much of the gnucash engine uses (b), although I notice that
someone has been running around using 'assert' which is maybe a no-no.

--linas