In article <d3jnpd$26hi$1@digitaldaemon.com>, Ben Hinkle says...
>>>"Sean Kelly" <sean@f4.ca> wrote in message news:d3jhab$20b2$1@digitaldaemon.com...>> Currently, auto classes are only deterministically destroyed if execution
>> leaves
>> scope normally, ie. if an exception is not thrown (see example below).
>[snip]
>>Interesting test. It could be a bug in exception handling and auto classes - it seems odd to run the dtor after both the try and catch scopes are gone. When I run
> auto class AutoClass {
> this() { printf( "ctor\n" ); }
> ~this() { printf( "dtor\n" ); }
> void yikes() { throw new Exception( "" ); }
> }
> void main() {
> try {
> auto AutoClass c = new AutoClass();
> c.yikes();
> } catch( Exception e ){
> printf( "caught\n" );
> }
> printf( "continue\n" );
> }
>>I get
>>D:\d>test
>ctor
>dtor
>caught
>continue
>>The only difference is throwing after the ctor vs inside.
Well that's interesting. So the problem is only when an exception is thrown from the ctor?
Either way, I'd like to know if anyone has issues with my suggestion, as it seems a simple way to address the Irrecoverable exception idea. Is there any reason RAII would require the auto classes to be cleaned up immediately upon scope exit rather than delaying this until catch scope exit? This practice causes a ton of problems in C++, and it would be nice if these problems could be so neatly eliminated while addressing Matthew's request at the same time.
Sean

> Either way, I'd like to know if anyone has issues with my suggestion, as
> it
> seems a simple way to address the Irrecoverable exception idea. Is there
> any
> reason RAII would require the auto classes to be cleaned up immediately
> upon
> scope exit rather than delaying this until catch scope exit? This
> practice
> causes a ton of problems in C++, and it would be nice if these problems
> could be
> so neatly eliminated while addressing Matthew's request at the same time.
I think the Matthew was proposing that the program exit at the end of the top-most catch block - not the immediate catch block. For example if foo1 calls foo2 calls foo3 and all have try catches then an unrecoverable exception thrown in foo3 will execute all the catches (or finally statements) in foo3, foo2, foo1 in order and then exit. From what I understand of your proposal the prog would exit at the catch with the auto, which I guess the user would have to make sure is the top.

In article <d3k1cf$2fdg$1@digitaldaemon.com>, Ben Hinkle says...
>>> Either way, I'd like to know if anyone has issues with my suggestion, as
>> it
>> seems a simple way to address the Irrecoverable exception idea. Is there
>> any
>> reason RAII would require the auto classes to be cleaned up immediately
>> upon
>> scope exit rather than delaying this until catch scope exit? This
>> practice
>> causes a ton of problems in C++, and it would be nice if these problems
>> could be
>> so neatly eliminated while addressing Matthew's request at the same time.
>>I think the Matthew was proposing that the program exit at the end of the top-most catch block - not the immediate catch block. For example if foo1 calls foo2 calls foo3 and all have try catches then an unrecoverable exception thrown in foo3 will execute all the catches (or finally statements) in foo3, foo2, foo1 in order and then exit. From what I understand of your proposal the prog would exit at the catch with the auto, which I guess the user would have to make sure is the top.
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.
# void f1() {
# try {
# auto Foo f = new Foo();
# throw new Exception("");
# catch(Exception e) {
# throw e;
# }
# }
#
# void f2() {
# try {
# auto Bar b = new Bar();
# f1();
# }
# catch(Exception e) {
# throw new Exception("");
# }
# }
#
# void f3() {
# try {
# f2();
# }
# catch(Exception e) {}
# // auto Foo f would be destroyed here, followed by auto Bar b
# }
The only slightly sticky issue I can think of is how do auto objects declared within one of the catch blocks fit into the destruction ordering scheme? Should destruction be strictly LIFO or should a more complex ordering be imposed?
Sean

> 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).

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).
Sean

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d3k1cf$2fdg$1@digitaldaemon.com...>> Either way, I'd like to know if anyone has issues with my
>> suggestion, as it
>> seems a simple way to address the Irrecoverable exception idea.
>> Is there any
>> reason RAII would require the auto classes to be cleaned up
>> immediately upon
>> scope exit rather than delaying this until catch scope exit?
>> This practice
>> causes a ton of problems in C++, and it would be nice if these
>> problems could be
>> so neatly eliminated while addressing Matthew's request at the
>> same time.
>> I think the Matthew was proposing that the program exit at the end of the top-most catch block - not the immediate catch block. For example if foo1 calls foo2 calls foo3 and all have try catches then an unrecoverable exception thrown in foo3 will execute all the catches (or finally statements) in foo3, foo2, foo1 in order and then exit. From what I understand of your proposal the prog would exit at the catch with the auto, which I guess the user would have to make sure is the top.
Ben describes it aright