[DGD] Error handling, possible bug
bart at wotf.org
bart at wotf.org
Mon Apr 3 18:16:36 CEST 2017
The code which does this looks very deliberate, from interpret.cpp, function
runtime_error:
case II_CATCH:
atomic = f->atomic;
p = f->prog + FETCH2U(pc, u);
try {
ec_push((ec_ftn) i_catcherr);
f->atomic = FALSE;
i_interpret0(f, pc);
ec_pop();
pc = f->pc;
*--f->sp = nil_value;
} catch (...) {
/* error */
f->pc = pc = p;
PUSH_STRVAL(f, errorstr());
}
f->atomic = atomic;
break;
I assume the intention is to only call this when an uncaught error occurs and
is going to trigger a rollback. A caught error in atomic code won't cause a
rollback and hence will let you gather information on the error and have that
information still available after having left the atomic context, which isn't
the case for an uncaught error, where atomic_error is the only way to get some
info about that error to the 'outside' non atomic world.
Bart.
On Mon, 3 Apr 2017 08:52:26 -0700, Raymond Jennings wrote
> Hey um...is it normal for atomic_error to be bypassed if an error
> within atomic context is caught?
>
> I was playing around with the "return a string from an error handler"
> feature and noticed that atomic_error got skipped if the error in
> question happens to be caught.
>
> Also, is there supposed to be any functional difference between
> catch(expression) and catch{statements}:{morestatement} in terms of
> calls to driver->foobar_error(...)?
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/
More information about the DGD
mailing list