[boost] Re: Re: Attempting resolution of Threads & Exceptions Issue

From: Andreas Huber (spam2002_at_[hidden])
Date: 2002-08-21 12:04:28

> You could make an attempt to return the card in the terminate handler,
too.

Yes I definitely could but it makes recovery more complicated. Lets take
this to a more general level: A program could have an arbitrary number of
such uncommited transactions pending when it happens to detect a programming
error. So you need some kind of rollback registry (probably with a second
kind of "scope" guard as front-end), which will undo all the already
committed stuff inside abort()/terminate(). This leaves one more decision to
programmers when they need to undo stuff in the face of errors (could be an
exception _or_ a programming error). I'd rather avoid this as long as there
are no strong reasons for it.

> The main problem with the "exceptions for programming errors" approach is
> that the error recovery code is never tested. If you encounter a
programming
> error during testing, you fix it; therefore, the programming errors that
> remain are unknown, and so is the reaction of the recovery code. :-)

I agree that there's no way to test the outcome of every possible
programming error in all possible contexts, but isn't the same is true when
you use the hypothetical rollback registry outlined above? Agreed, the
number of rollbacks executed inside abort()/terminate() is probably several
magnitudes smaller than the number of actions executed as part of a
stack-unwind, so the rollback registry approach is probably more secure.
However, you still can't test it properly.

Regards,

Andreas