View mode: basic / threaded / horizontal-split · Log in · Help
April 14, 2005
Re: Proposal:
"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?
April 14, 2005
Re: Proposal:
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
April 16, 2005
Re: Proposal: "auto" and exceptions
"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.
April 17, 2005
Re: Proposal:
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home