Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ exception handling is defective

Reply
Thread Tools

C++ exception handling is defective

 
 
Zorro
Guest
Posts: n/a
 
      01-09-2007
The simplicity of stack unraveling of C++ is not without defective
consequences. The following article points to C++ examples showing the
defects. An engineer aware of defects can avoid hard-to-find bugs.

http://distributed-software.blogspot...defective.html

Regards,

http://www.zhmicro.com
http://distributed-software.blogspot.com
http://groups-beta.google.com/group/...Z?lnk=la&hl=en

 
Reply With Quote
 
 
 
 
Rolf Magnus
Guest
Posts: n/a
 
      01-09-2007
Zorro wrote:

> The simplicity of stack unraveling of C++ is not without defective
> consequences. The following article points to C++ examples showing the
> defects. An engineer aware of defects can avoid hard-to-find bugs.
>
>

http://distributed-software.blogspot...defective.html

None of the C++ examples in the PDF linked from there is actually using
exception handling. They all invoke undefined behavior. They don't show a
defect in C++'s exception handling, but rather a lack of the author's
understanding of C++.

BTW: Those examples are also using the <iostream.h> header that has been
outdated in C++ for about 10 years now and has actually never even been
part of the C++ Standard.

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      01-09-2007
Rolf Magnus wrote:
> Zorro wrote:
>
>
>>The simplicity of stack unraveling of C++ is not without defective
>>consequences. The following article points to C++ examples showing the
>>defects. An engineer aware of defects can avoid hard-to-find bugs.
>>
>>

>
> http://distributed-software.blogspot...defective.html
>
> None of the C++ examples in the PDF linked from there is actually using
> exception handling. They all invoke undefined behavior. They don't show a
> defect in C++'s exception handling, but rather a lack of the author's
> understanding of C++.
>

Agreed, I wonder which compiler and environment produced the results
claimed.

> BTW: Those examples are also using the <iostream.h> header that has been
> outdated in C++ for about 10 years now and has actually never even been
> part of the C++ Standard.
>

Not to mention idiomatic C (void).

--
Ian Collins.
 
Reply With Quote
 
David W
Guest
Posts: n/a
 
      01-09-2007
"Zorro" <> wrote in message
news: oups.com...
> The simplicity of stack unraveling of C++ is not without defective
> consequences. The following article points to C++ examples showing the
> defects. An engineer aware of defects can avoid hard-to-find bugs.
>
>

http://distributed-software.blogspot...ing-is-defecti
ve.html

The fact that the code samples use <iostream.h> and not <iostream> suggests that
a very old compiler was used to demonstrate the supposed exception bugs. If the
code is updated for <iostream> and the divisions by zero are replaced by throws
(/0 causes undefined behaviour) and a more recent compiler is used, I think
you'll find that the destructor is indeed called when the stack is unwound. It
looks like a defective compiler rather than a defective language.

DW


 
Reply With Quote
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      01-10-2007
David W wrote:

> The fact that the code samples use <iostream.h> and not <iostream>
> suggests that a very old compiler was used to demonstrate the supposed
> exception bugs. If the code is updated for <iostream> and the divisions by
> zero are replaced by throws (/0 causes undefined behaviour) and a more
> recent compiler is used, I think you'll find that the destructor is indeed


Better say a correct compiler. I have seen Borland Kilyx failing to call
destructors in cases similar to that (but correct). I even asked here if
the code has some error I failed to see, if I remember well. And Borland
acknowledged the bug, but failed to provide a solution (at least during the
time that I have the patience to keep checking).

--
Salu2
 
Reply With Quote
 
Zorro
Guest
Posts: n/a
 
      01-10-2007

Zorro wrote:
> The simplicity of stack unraveling of C++ is not without defective
> consequences. The following article points to C++ examples showing the
> defects. An engineer aware of defects can avoid hard-to-find bugs.
>
> http://distributed-software.blogspot...defective.html
>
> Regards,
>
> http://www.zhmicro.com
> http://distributed-software.blogspot.com
> http://groups-beta.google.com/group/...Z?lnk=la&hl=en


This is a common reply to several comments, respectfully.

1. The use of one or another header file is cosmetic for this example.
2. When you say a correct compiler will do better, please specify the
compiler.
3. Division by 0 happens at system level and is not necessary to turn
it into a throw.
4. For this example, the compiler is Microsoft Visual C++ version 6.
5. The defect is in the technique used. Of course it can be corrected.
Show me a compiler that has in fact corrected this problem. The point
is that, it takes a great deal beyond plain stack unraveling to correct
this problem.
6. If you are not familiar with the concept, and do not see the real
issue, avoid revealing it.

With respect, the best way I could present my response.

Regards,

http://www.zhmicro.com
http://distributed-software.blogspot.com
http://groups-beta.google.com/group/...Z?lnk=la&hl=en

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-10-2007
Zorro wrote:
> Zorro wrote:
>
>>The simplicity of stack unraveling of C++ is not without defective
>>consequences. The following article points to C++ examples showing the
>>defects. An engineer aware of defects can avoid hard-to-find bugs.
>>
>>http://distributed-software.blogspot...defective.html
>>
>>Regards,
>>
>>http://www.zhmicro.com
>>http://distributed-software.blogspot.com
>>http://groups-beta.google.com/group/...Z?lnk=la&hl=en

>
>
> This is a common reply to several comments, respectfully.
>
> 1. The use of one or another header file is cosmetic for this example.


It may or may not be cosmetic, but is asking for flak.

> 2. When you say a correct compiler will do better, please specify the
> compiler.


Changing you example to standard C++:

#include <iostream>

struct simple
{
int s;
simple() { s = 5;}
~simple(void) {std::cout << "Destructor ..." << std::endl;}
};

int main(){
int i = 1, j = 0;
try {
simple spl;
throw 0;
}
catch(...) {
std::cout << "Caught it" << std::endl;
}
std::cout << "Finishing" << std::endl;
return 0;
}

any compiler should give the correct result. If not, it is broken.

> 3. Division by 0 happens at system level and is not necessary to turn
> it into a throw.


Then why use it in your examples?

> 4. For this example, the compiler is Microsoft Visual C++ version 6.


Old and not very compliant.

> 5. The defect is in the technique used. Of course it can be corrected.
> Show me a compiler that has in fact corrected this problem. The point
> is that, it takes a great deal beyond plain stack unraveling to correct
> this problem.


Show me one that exibits it.

> 6. If you are not familiar with the concept, and do not see the real
> issue, avoid revealing it.
>

Which concept?

--
Ian Collins.
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      01-10-2007
Zorro wrote:

>
> Zorro wrote:
>> The simplicity of stack unraveling of C++ is not without defective
>> consequences. The following article points to C++ examples showing the
>> defects. An engineer aware of defects can avoid hard-to-find bugs.
>>
>>

http://distributed-software.blogspot...defective.html
>>
>> Regards,
>>
>> http://www.zhmicro.com
>> http://distributed-software.blogspot.com
>> http://groups-beta.google.com/group/...Z?lnk=la&hl=en

>
> This is a common reply to several comments, respectfully.
>
> 1. The use of one or another header file is cosmetic for this example.
> 2. When you say a correct compiler will do better, please specify the
> compiler.


Your compiler did just fine. The output you present is a perfectly valid
output for the program.

> 3. Division by 0 happens at system level and is not necessary to turn
> it into a throw.


The problem with the division by 0 is that it simply is undefined behavior
according to the standard. The language specification places no
requirements upon the observable behavior of any program that executed a
division by 0. Therefore, the output you attribute to incorrect handling of
exceptions is a perfectly valid output for your program (and so would be
any other).

What puts your program into an inconsistent state is not some exception but
the division by 0, which is UB.

> 4. For this example, the compiler is Microsoft Visual C++ version 6.
> 5. The defect is in the technique used. Of course it can be corrected.


The defect lies in the undefined behavior.

> Show me a compiler that has in fact corrected this problem. The point
> is that, it takes a great deal beyond plain stack unraveling to correct
> this problem.


Your program does not illustrate problem with stack unravelling. It
illustrates that all bets are off once you have undefined behavior.

> 6. If you are not familiar with the concept, and do not see the real
> issue, avoid revealing it.


Huh?


Best

Kai-Uwe Bux
 
Reply With Quote
 
Zorro
Guest
Posts: n/a
 
      01-10-2007

Kai-Uwe Bux wrote:
> Zorro wrote:
>
> >
> > Zorro wrote:
> >> The simplicity of stack unraveling of C++ is not without defective
> >> consequences. The following article points to C++ examples showing the
> >> defects. An engineer aware of defects can avoid hard-to-find bugs.
> >>
> >>

> http://distributed-software.blogspot...defective.html
> >>
> >> Regards,
> >>
> >> http://www.zhmicro.com
> >> http://distributed-software.blogspot.com
> >> http://groups-beta.google.com/group/...Z?lnk=la&hl=en

> >
> > This is a common reply to several comments, respectfully.
> >
> > 1. The use of one or another header file is cosmetic for this example.
> > 2. When you say a correct compiler will do better, please specify the
> > compiler.

>
> Your compiler did just fine. The output you present is a perfectly valid
> output for the program.
>
> > 3. Division by 0 happens at system level and is not necessary to turn
> > it into a throw.

>
> The problem with the division by 0 is that it simply is undefined behavior
> according to the standard. The language specification places no
> requirements upon the observable behavior of any program that executed a
> division by 0. Therefore, the output you attribute to incorrect handling of
> exceptions is a perfectly valid output for your program (and so would be
> any other).
>
> What puts your program into an inconsistent state is not some exception but
> the division by 0, which is UB.
>
> > 4. For this example, the compiler is Microsoft Visual C++ version 6.
> > 5. The defect is in the technique used. Of course it can be corrected.

>
> The defect lies in the undefined behavior.
>
> > Show me a compiler that has in fact corrected this problem. The point
> > is that, it takes a great deal beyond plain stack unraveling to correct
> > this problem.

>
> Your program does not illustrate problem with stack unravelling. It
> illustrates that all bets are off once you have undefined behavior.
>
> > 6. If you are not familiar with the concept, and do not see the real
> > issue, avoid revealing it.

>
> Huh?
>
>
> Best
>
> Kai-Uwe Bux


Kai-Uwe, division by 0 is undefined just as trying to deref a null
pointer. These are exceptional cases that can happen. Simply calling
them (undefined behavior) does not help in anyway. Are you saying that,
if one of these cases, or many similar ones, happens the program should
necessarily terminate? Then what is the point of having an exception
mechanism?
Yes, the output is correct in accordance to C++ standard. But, is it
acceptable just because that is how it is?

Thanks for your contribution as it brought one more point to attention.

Regards,

http://www.zhmicro.com
http://distributed-software.blogspot.com
http://groups-beta.google.com/group/...Z?lnk=la&hl=en

 
Reply With Quote
 
Zorro
Guest
Posts: n/a
 
      01-10-2007

Ian Collins wrote:
> Zorro wrote:
> > Zorro wrote:
> >
> >>The simplicity of stack unraveling of C++ is not without defective
> >>consequences. The following article points to C++ examples showing the
> >>defects. An engineer aware of defects can avoid hard-to-find bugs.
> >>
> >>http://distributed-software.blogspot...defective.html
> >>
> >>Regards,
> >>
> >>http://www.zhmicro.com
> >>http://distributed-software.blogspot.com
> >>http://groups-beta.google.com/group/...Z?lnk=la&hl=en

> >
> >
> > This is a common reply to several comments, respectfully.
> >
> > 1. The use of one or another header file is cosmetic for this example.

>
> It may or may not be cosmetic, but is asking for flak.
>
> > 2. When you say a correct compiler will do better, please specify the
> > compiler.

>
> Changing you example to standard C++:
>
> #include <iostream>
>
> struct simple
> {
> int s;
> simple() { s = 5;}
> ~simple(void) {std::cout << "Destructor ..." << std::endl;}
> };
>
> int main(){
> int i = 1, j = 0;
> try {
> simple spl;
> throw 0;
> }
> catch(...) {
> std::cout << "Caught it" << std::endl;
> }
> std::cout << "Finishing" << std::endl;
> return 0;
> }
>
> any compiler should give the correct result. If not, it is broken.
>
> > 3. Division by 0 happens at system level and is not necessary to turn
> > it into a throw.

>
> Then why use it in your examples?
>
> > 4. For this example, the compiler is Microsoft Visual C++ version 6.

>
> Old and not very compliant.
>
> > 5. The defect is in the technique used. Of course it can be corrected.
> > Show me a compiler that has in fact corrected this problem. The point
> > is that, it takes a great deal beyond plain stack unraveling to correct
> > this problem.

>
> Show me one that exibits it.
>
> > 6. If you are not familiar with the concept, and do not see the real
> > issue, avoid revealing it.
> >

> Which concept?
>
> --
> Ian Collins.


Ian, the stream library for output is not the issue. I only tried to
write less because that was not the point. However, you are replacing
division by 0 with a throw. What the example is speaking of is about
exceptions that can happen without you throwing them. Although I am not
saying that your version does not fail.

The concept I am referring to is exceptional events that can happen as
your program executes. For instance, the operating system does not die
on a division by 0. It simply aborts your program. Thus, the point is
that, a C++ compiler's run-time library must sense and report such
events to your program so you can do something about them. Indeed, in
this example the compiler does report. The problem is the way the
run-time library is handling the recovery, known as stack unraveling.
One needs to do a few more things as housekeeping besides popping the
stack, and passing the exception to the next call.

Thanks for your comment.

Regards,

http://www.zhmicro.com
http://distributed-software.blogspot.com
http://groups-beta.google.com/group/...Z?lnk=la&hl=en

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
signal handling and (structured) exception handling Peter C++ 34 10-17-2009 10:03 AM
Exception of type 'System.Web.HttpUnhandledException' wasthrown.Exception has been thrown by the target of an invocation.System.WebSystem.Exception jobs ASP .Net 1 11-16-2007 05:57 PM
while executing my client program i get the exception javax.naming.LinkException: [Root exception is javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException: remaining if plz anybody know how to solve this problem then mahesh Java 0 03-08-2007 12:26 PM
SoapExtension for Global Exception handling; but prevent exception from propagating!! VSK ASP .Net Web Services 0 07-29-2003 05:39 PM
Defective Search Routine Unsigned Computer Support 2 07-11-2003 03:59 AM



Advertisments