473,880 Members | 1,753 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

C++ exception handling is defective

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,
zo****@ZHMicro. com
http://www.zhmicro.com
http://distributed-software.blogspot.com
http://groups-beta.google.com/group/...Z?lnk=la&hl=en

Jan 9 '07
132 5683
Zorro wrote:
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.
What the operating system does has nothing to do with the issue.
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.
The point is that all compilers must do what you want just because you like
it that way? If not, there are tons of books and other resources that
explains the reasons for the design decisions of the C++ language.

--
Salu2
Jan 10 '07 #21
Hello!

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
I've read this thread, as well as your blog article and referenced
document (which seems to be plugging your Z++), and it seems you're
misunderstandin g /why/ the behaviour of division by zero is undefined.

My guess is that the rationale behind it being undefined is something
like the following.

When a processor encounters division by zero, it may well throw an
exception (*not* a C++ exception), complain in some other way, ignore
it, or do something else. What it does depends on the processor. But,
whatever it is, it's beyond the scope of the C++ standard, because the
C++ standard is not there to define such processor behaviour.

If a processor somehow reports division by zero to, say, an operating
system, then that operating system may well respond by sending a signal
to the relevant program, terminating execution of that program, ignoring
it, or doing something else. What it does depends on the operating
system. But, whatever it is, it's beyond the scope of the C++ standard,
because the C++ standard is not there to define such operating system
behaviour.

If the C++ standard was to specify behaviour for division by zero, then
since the processor's behaviour and operating system's behaviour are
beyond the scope of the C++ standard, such specified behaviour may well
have to be implemented in such a way as to prevent the division by zero
from actually occurring in the first place. That would impose often
unnecessary and unwanted overheads. C++ just isn't that sort of language.

Indeed, there are a great many unsafe things that C++ allows programmers
to do. There are unsafe things that C++ allows programmers to do
without even throwing C++ exceptions when they're done. Instead, C++
provides mechanisms for use /when the programmer wants or needs them./
It's the programmer's responsibility to write safe code, /not/ C++
itself. So, C++ provides exception mechanisms /without/ imposing them
on the programmer. If the programmer needs well-behaved exception
handling, the programmer can then use the exception mechanisms provided
accordingly. That's the kind of language that C++ is.

So, if, when doing a division, there's the real (though hopefully
exceptional) possibility of it being a division by zero, the thing to do
is to do that division within a try block, checking for division by zero
before doing the division, and throwing an exception if it would be
division by zero. This could, of course, be wrapped up in your own
number class. No need to change the language itself.

:-)

--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Jan 10 '07 #22
IR
Zorro wrote:
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.
Basically, you're just saying that RAII in C++ is broken.
This is a tough statement, you're gonna have hard time proving it...

Incidentally, as others already mentionned it, you should start using
a recent compiler.

Cheers,
--
IR
Jan 10 '07 #23

Simon G Best wrote:
Hello!

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

I've read this thread, as well as your blog article and referenced
document (which seems to be plugging your Z++), and it seems you're
misunderstandin g /why/ the behaviour of division by zero is undefined.

My guess is that the rationale behind it being undefined is something
like the following.

When a processor encounters division by zero, it may well throw an
exception (*not* a C++ exception), complain in some other way, ignore
it, or do something else. What it does depends on the processor. But,
whatever it is, it's beyond the scope of the C++ standard, because the
C++ standard is not there to define such processor behaviour.

If a processor somehow reports division by zero to, say, an operating
system, then that operating system may well respond by sending a signal
to the relevant program, terminating execution of that program, ignoring
it, or doing something else. What it does depends on the operating
system. But, whatever it is, it's beyond the scope of the C++ standard,
because the C++ standard is not there to define such operating system
behaviour.

If the C++ standard was to specify behaviour for division by zero, then
since the processor's behaviour and operating system's behaviour are
beyond the scope of the C++ standard, such specified behaviour may well
have to be implemented in such a way as to prevent the division by zero
from actually occurring in the first place. That would impose often
unnecessary and unwanted overheads. C++ just isn't that sort of language.

Indeed, there are a great many unsafe things that C++ allows programmers
to do. There are unsafe things that C++ allows programmers to do
without even throwing C++ exceptions when they're done. Instead, C++
provides mechanisms for use /when the programmer wants or needs them./
It's the programmer's responsibility to write safe code, /not/ C++
itself. So, C++ provides exception mechanisms /without/ imposing them
on the programmer. If the programmer needs well-behaved exception
handling, the programmer can then use the exception mechanisms provided
accordingly. That's the kind of language that C++ is.

So, if, when doing a division, there's the real (though hopefully
exceptional) possibility of it being a division by zero, the thing to do
is to do that division within a try block, checking for division by zero
before doing the division, and throwing an exception if it would be
division by zero. This could, of course, be wrapped up in your own
number class. No need to change the language itself.

:-)

--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
There are a number of great comments, but this one sums it up rather
thoroughly.

What seems to be happening is this. When you use "throw", the compiler
generates code to destroy objects in relevant scopes, should an
exception happen. Otherwise, the compiler has no clue where to put such
code. Thus, even though exceptions (such as div by zero) are caught,
the code to call destructors (at end of try, or function body) is
simply skipped.

What that all means, again is this. There is code to destroy objects in
nested scopes. However, unless the "throw" is used, the compiler will
be caught unguarded, and code for destroying objects will be skipped.

That is fair as a standard. The compiler is just doing what the
standard requires, even VC++ 6 does it right. It is also fair to expect
the engineer to check for every possible case of exception and put a
"throw" for it.

I have no further argument on this issue. Just a comment, and nothing
else.

Given that all operating systems report errors (exceptions) rather than
crashing, and in fact the program can even check the error code, etc.
and continue to execute (perhaps taking the necessary actions), how
hard is it for the standard to have a list of common exceptions that
may happen unexpectedly?
The answer is that, the mechanism used in C++ still will need the
"throw" in order to generate code for NOT skipping the destruction of
objects.
I hope this helps, but it is not intended to start another wave. I
agree with all of you.

Thanks for your comments. Have a great day.

Regards,
zo****@ZHMicro. com
http://www.zhmicro.com
http://distributed-software.blogspot.com
http://groups-beta.google.com/group/...Z?lnk=la&hl=en

Jan 11 '07 #24
Zorro wrote:
Given that all operating systems report errors (exceptions) rather than
crashing, and in fact the program can even check the error code, etc.
Invalid reasoning, because the premise is false. Unless you use a definition
of "Operating system" that excludes, for example, ms-dos.

--
Salu2
Jan 11 '07 #25
Zorro wrote:
>
Given that all operating systems report errors (exceptions) rather than
crashing, and in fact the program can even check the error code, etc.
and continue to execute (perhaps taking the necessary actions), how
hard is it for the standard to have a list of common exceptions that
may happen unexpectedly?
Not all implementations are hosted. Even those that are (UNIX like
systems for example) may signal exception asynchronously. This makes it
extremely difficult to handle the event in the same context as the
running application in order to convert the system event into an
application one.

--
Ian Collins.
Jan 11 '07 #26
Zorro wrote:
>
What seems to be happening is this. When you use "throw", the compiler
generates code to destroy objects in relevant scopes, should an
exception happen. Otherwise, the compiler has no clue where to put such
code. Thus, even though exceptions (such as div by zero) are caught,
the code to call destructors (at end of try, or function body) is
simply skipped.
No. If div by zero throws an exception that's implementation-specific
behavior. If your implementation does something silly like not run
destructors as part of its implemenation-specific behavior, that's a
problem with your implementation, not with the language.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Jan 11 '07 #27

Zorro wrote:
how
hard is it for the standard to have a list of common exceptions that
may happen unexpectedly?
I suspect much harder than it is for you to write

#include <eh.h>

void my_handler(UINT , struct _EXCEPTION_POIN TERS* pex)
{
if(pex->ExceptionRecor d->ExceptionCod e ==
EXCEPTION_INT_D IVIDE_BY_ZERO)
throw divide_by_zero( );
}

// main
_set_se_transla tor(&my_handler );

Jan 11 '07 #28
Zorro wrote:
how
hard is it for the standard to have a list of common exceptions that
may happen unexpectedly?
The standard has a list of all standard exceptions. Keep in mind that
hardware "exceptions " are not the same as C++ exceptions, although they
use the same name. C++ doesn't say much about hardware exceptions,
because they're too idiosyncratic. If you don't throw it, it's not
covered by the standard.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Jan 11 '07 #29
Zorro wrote:
What seems to be happening is this. When you use "throw", the compiler
generates code to destroy objects in relevant scopes, should an
exception happen. Otherwise, the compiler has no clue where to put such
code. Thus, even though exceptions (such as div by zero) are caught,
the code to call destructors (at end of try, or function body) is
simply skipped.
You're wrong.
`throw' simply throws exceptions.
If you don't use `throw', no exception is thrown. `throw' is the only
way to throw exceptions in C++.
It has been told to you more than ten times already, but division by
zero does *not* throw any exception.
Given that all operating systems report errors (exceptions) rather than
crashing
Not all do, on some machines couldn't even allow it.
Jan 11 '07 #30

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
2347
by: Daniel Wilson | last post by:
I am having exception-handling and stability problems with .NET. I will have a block of managed code inside try...catch and will still get a generic ..NET exception box that will tell me which assemblies are loaded before shutting down. In one case, some of my DB-accessing code didn't handle a NULL value properly. But try...catch wouldn't catch the exception and keep going. I'd just get the error message and then it would shut the...
7
6012
by: Noor | last post by:
please tell the technique of centralize exception handling without try catch blocks in c#.
3
2757
by: Master of C++ | last post by:
Hi, I am an absolute newbie to Exception Handling, and I am trying to retrofit exception handling to a LOT of C++ code that I've written earlier. I am just looking for a bare-bones, low-tech exception handling mechanism which will allow me to pass character information about an error and its location from lower-level classes. Can you please critique the following exception handling mechanism in terms of my requirements ?
9
2545
by: C# Learner | last post by:
Some time ago, I remember reading a discussion about the strengths and weaknesses of exception handling. One of the weaknesses that was put forward was that exception handling is inefficient (in the way of CPU usage), compared to the "normal" practise returning values. How true is this? Will using using exception handling, in general, be much less efficient than returning values, or less efficient at all? Just curious...
4
5143
by: Ele | last post by:
When Exception handling disabled compiler still spits out "C++ exception handler used." Why is that? Why does it ask for "Specify /EHsc"? Thanks! c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstring(1453) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
41
3094
by: Zytan | last post by:
Ok something simple like int.Parse(string) can throw these exceptions: ArgumentNullException, FormatException, OverflowException I don't want my program to just crash on an exception, so I must handle all of them. I don't care about which one happened, except to write out exception.Message to a log file. It seems verbose to write out three handlers that all do the same thing. So, I could just catch Exception. But, is that...
1
3115
by: George2 | last post by:
Hello everyone, Such code segment is used to check whether function call or exception- handling mechanism runs out of memory first (written by Bjarne), void perverted() { try{
0
9774
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11093
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10715
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10811
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9550
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7105
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5778
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5973
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
3
3220
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.