"Sean Kelly" <sean@f4.ca> wrote in message news:d3k88o$2l35$1@digitaldaemon.com...
> In article <d3k73p$2k73$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>> No.  I was proposing that auto class destruction be deferred
>>> until a catch
>>> clause exits normally rather than with another throw exception.
>>> By
>>> Matthew's
>>> terminology, that would be the top-most catch block.  ie.
>>
>>Plus Matthew would require all catch blocks to rethrow
>>automatically until
>>the top-most block. Otherwise with the foo1, foo2, foo3 example if
>>foo2
>>didn't rethrow then it would leave the catch block normally and
>>foo1's catch
>>wouldn't run. I understand Matthew's request as: if an instance of
>>a certain
>>class of objects is thrown then all catch blocks on the stack
>>automatically
>>rethrow if the catch block is exited normally (ie - no catch block
>>can be
>>exited normally).
>
> But the point of forcing a rethrow all the way out of main would
> just be to
> insure termination, correct?  If so, this would be handled by
> terminate() in the
> class dtor in my suggestion.  My only (growing) reservation is
> that I'm not
> entirely happy with the impact on auto objects in evaluated catch
> blocks, as I
> think they should be destroyed *after* the in-function auto
> objects whose
> destruction was deferred.  ie. I would want destruction to be
> delayed, but
> destruction order to be preserved, and this isn't strictly LIFO,
> which would
> slightly complicate implementation (and explanation).

It's also because different levels of the call chain should be given a bite at the last-gasps-of-life in an irrecoverable situation. Otherwise, how does one decide, from a program behavioural policy point of view, who should get it?

In article <d3kpul$30kk$2@digitaldaemon.com>, Matthew says...
>
>It's also because different levels of the call chain should be given a bite at the last-gasps-of-life in an irrecoverable situation. Otherwise, how does one decide, from a program behavioural policy point of view, who should get it?

To me, an Error is just like any other exception but for the fact that it is not recoverable.  And so long as errors are not grouped under the Exception umbrella, the client will have to catch them explicitly anyway.  I have nothing against re-throwing all the way up the call chain--it just seems unnecessary so long as the application terminates when the client is done with it.  How far that Error gets, IMO, is entirely up to the client, just so long as the choice is made explicitly.


Sean

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d3jnpd$26hi$1@digitaldaemon.com...
> The only difference is throwing after the ctor vs inside.

That's right. The issue here is what happens when an exception is thrown within a constructor. It is not an issue of autos being cleaned up if an exception gets thrown - they are.

In article <d3q6i9$1th4$2@digitaldaemon.com>, Walter says...
>
>
>"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d3jnpd$26hi$1@digitaldaemon.com...
>> The only difference is throwing after the ctor vs inside.
>
>That's right. The issue here is what happens when an exception is thrown within a constructor. It is not an issue of autos being cleaned up if an exception gets thrown - they are.

Yup.  My mistake for grabbing my example from a collection of bug tests on exceptions... and picking one that demonstrated a different problem.  The only bug in the code I posted is that the class dtor is called at all.


Sean