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
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
