From: dave@boostpro.com
on Wed Jun 27 2012, DeMarcus wrote:
>>> I claim that the most recent exception must be what is caught at
>>> the next catch().
>>
>> I disagree. Suppose you have a recovery action for the most recent
>> exception, and you take it, and retry? The original reason for
>> failure persists, and the operation still fails. Not good.
>
> This is a tricky one. As you say, what's the point retrying if the
> root cause persists? On the other hand, if we take a look a bit up
> in the call stack, it's not likely that the code there will look for
> and catch out-of-bounds exceptions caused a long road down the call
> stack.
It's not likely that any code will look for and catch out-of-bounds
exceptions, since they usually represent programming errors, and
nobody can maintain his sanity while coding as though the program is
broken.
>>> That prioritization is not obvious and I claim it must not be left
>>> as a side task.
>>
>> What do you mean by a "side task?"
>
> I mean that in order to deal with secondary exceptions you must
> really know what you are doing and have a firm coding convention to
> deal with them, otherwise we risk unsafe exception handling when
> people start to throw from destructors without knowing how to deal
> with the several exceptions that might be generated.
Meh. The program is already "on the unwinding path." I don't see how
the secondary exception is going to meaninfully impact safety.
>> My plan is to leave it up to the author of the hook function for
>> dealing with nested exceptions. My claim is that "ignore secondary
>> exceptions" might be a reasonable default, "chain the secondary
>> exception to the first" might be better, "terminate" would be what
>> you'd choose for absolute backward compatibility, and if you are
>> are foolish enough to disagree with me about what should be at the
>> head of the chain then you're free to do it the "wrong" way ;-)
>>
>
> I think we agree on most parts now, but I'm not sure that I've
> managed to explain what I mean with independent failures.
>
> There is a small risk, small but still a risk, that one destructor
> throws a secondary exception for some completely independent reason
> when another exception is active (some other function threw).
Yes.
> Then "ignore secondary exceptions" would be the same as
>
> try
> {
> fnc();
> }
> catch( SecondaryException& )
> {
> // Swallow the secondary exception and do nothing!
> }
No, it wouldn't be the same, because the stack is already unwinding.
> I don't agree that it's a reasonable default.
>
> That is what I meant with bulking. Somehow, you must be able to deal
> with /multiple/ exception chains. Just putting a completely
> independent secondary exception in the same chain as the active
> exception chain will, in best case, lead to that the secondary
> exception is missed and lost.
There's no loss; the chains I'm talking about can be walked and
inspected by exception handling code.
> In worst case, the application or person reading the log will think
> it was part of the active failure and take action from that.
>
> Allowing secondary exceptions may lead to something better, but I
> think there must be some recommendations and guidelines how to use
> it.
Of course there must be guidelines. You just don't seem to agree that
one reasonable guideline is "just ignore that one."
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
