473,708 Members | 2,363 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Exception Handling and Refactoring Question ...

Hi,

I am writing a simulation package in C++, and so far I've written about
8000 lines of code and have about 30 classes. I haven't used C++
exceptions so far (for various reasons). The only two "resources" I use
are memory and file I/O and whenever there is a memory allocation
failure or file I/O failure I just simply call a custom assert-type
function to check, print a error message and abort. This seems to be OK
for now (for the simulator base development), but when I start writing
a GUI to the simulator, I would require a more graceful way to handle
such exceptional situations.

Now, I am reading all the good things about C++ exception handling and
I am considering refactoring my code to use try-catch type exception
handling. Agreed, I should have thought about this before I started
writing a single line of code (my programming skills were much inferior
then) - But now that I've come this far, is it worth to do the
refactoring ?, or is it even possible without a complete redesign of
everything ? (because I've read in many places that exception handling
should be tightly coupled with the overall design). My other option is
to expand on the custom assert-type function to do more than just
display an error message and abort.

Any suggestions, pointers or references will be greatly appreciated.

Thanks,
Vijay.

--
PS (flame-guard): My id "Master of C++" has more to do with my favorite
album "Master of Puppets" than with my proficiency in C++.

Jul 23 '05 #1
11 3270
"Master of C++" <ma************ *@gmail.com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .
Hi,

I am writing a simulation package in C++, and so far I've written about
8000 lines of code and have about 30 classes. I haven't used C++
exceptions so far (for various reasons). The only two "resources" I use
are memory and file I/O and whenever there is a memory allocation
failure or file I/O failure I just simply call a custom assert-type
function to check, print a error message and abort. This seems to be OK
for now (for the simulator base development), but when I start writing
a GUI to the simulator, I would require a more graceful way to handle
such exceptional situations.

Now, I am reading all the good things about C++ exception handling and
I am considering refactoring my code to use try-catch type exception
handling. Agreed, I should have thought about this before I started
writing a single line of code (my programming skills were much inferior
then) - But now that I've come this far, is it worth to do the
refactoring ?, or is it even possible without a complete redesign of
everything ? (because I've read in many places that exception handling
should be tightly coupled with the overall design). My other option is
to expand on the custom assert-type function to do more than just
display an error message and abort.

Any suggestions, pointers or references will be greatly appreciated.

Thanks,
Vijay.

--
PS (flame-guard): My id "Master of C++" has more to do with my favorite
album "Master of Puppets" than with my proficiency in C++.


I suggest you use ASSERT for errors which could only be caused by
programming errors and exceptions for errors which can be caused by
incorrect user input. The whole point of ASSERT is to help you with your
software testing. Since it drops out in the production code it is of no use
to the end user. Exception programming can be used to facilitate automatic
recovery (difficult but necessary in mission critical applications) or just
to make Good Error Messages -- "GEMs" (much easier).

You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input. Exceptions
can be a good way to deal with that problem, but considerable thought must
go into it. If your objective is just GEMs, you must ask yourself if your
end user is going to be able to figure out what he did wrong based on the
message you are giving him. I wish the programmers of some of the software I
use had thought about this a little more.

A console mode program which was just going for GEMs would look like this:

int main()
{
try {
start_running() ;
} catch (std::exception &e) {
std::cerr << e.what() << '\n';
}
}

Just derive all of your exception classes from std::exception and this is
it! In principle you don't need to write any other try blocks in the entire
program. Can't get much simpler than that.

Google for "programmin g by contract" to see some interesting ideas about how
to organize ASSERT programming.

HTH

--
Cy aka "Mastered by C++"
http://home.rochester.rr.com/cyhome/
Jul 23 '05 #2
GB
Cy Edmunds wrote:
You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input. Exceptions
can be a good way to deal with that problem, but considerable thought must
go into it. If your objective is just GEMs, you must ask yourself if your
end user is going to be able to figure out what he did wrong based on the
message you are giving him. I wish the programmers of some of the software I
use had thought about this a little more.

A console mode program which was just going for GEMs would look like this:

int main()
{
try {
start_running() ;
} catch (std::exception &e) {
std::cerr << e.what() << '\n';
}
}

Just derive all of your exception classes from std::exception and this is
it! In principle you don't need to write any other try blocks in the entire
program. Can't get much simpler than that.


If you are going to use the standard library exception classes the way
they were intended, then errors that occur in the environment of the
program, such as user errors, device I/O errors, or resource errors,
should be derived from std::runtime_er ror, not std::exception. Logic
errors of the type traditionally represented by assertions should derive
from std::logic_erro r (if you want to use exceptions for this). I would
expect to find this sort of exception primarily in library code that is
intended to be widely reused and must perform parameter validation
without asserting.

Gregg
Jul 23 '05 #3
GB
Cy Edmunds wrote:
You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input. Exceptions
can be a good way to deal with that problem, but considerable thought must
go into it. If your objective is just GEMs, you must ask yourself if your
end user is going to be able to figure out what he did wrong based on the
message you are giving him. I wish the programmers of some of the software I
use had thought about this a little more.

A console mode program which was just going for GEMs would look like this:

int main()
{
try {
start_running() ;
} catch (std::exception &e) {
std::cerr << e.what() << '\n';
}
}

Just derive all of your exception classes from std::exception and this is
it! In principle you don't need to write any other try blocks in the entire
program. Can't get much simpler than that.


If you are going to use the standard library exception classes the way
they were intended, then exception classes representing errors that
occur in the environment of the program, such as user errors, device I/O
errors, or resource errors, should be derived from std::runtime_er ror,
not std::exception. Exception classes representing logic errors of the
type traditionally represented by assertions should derive from
std::logic_erro r (if you want to use exceptions for this). I would
expect to find this sort of exception primarily in library code that is
intended to be widely reused and which must perform parameter validation
without asserting.

Gregg
Jul 23 '05 #4
"GB" <gb@invalid.inv alid> wrote in message
news:1E_Rd.1569 04$Jk5.141149@l akeread01...
Cy Edmunds wrote:
You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input.
Exceptions can be a good way to deal with that problem, but considerable
thought must go into it. If your objective is just GEMs, you must ask
yourself if your end user is going to be able to figure out what he did
wrong based on the message you are giving him. I wish the programmers of
some of the software I use had thought about this a little more.

A console mode program which was just going for GEMs would look like
this:

int main()
{
try {
start_running() ;
} catch (std::exception &e) {
std::cerr << e.what() << '\n';
}
}

Just derive all of your exception classes from std::exception and this is
it! In principle you don't need to write any other try blocks in the
entire program. Can't get much simpler than that.
If you are going to use the standard library exception classes the way
they were intended, then errors that occur in the environment of the
program, such as user errors, device I/O errors, or resource errors,
should be derived from std::runtime_er ror, not std::exception.


You have confused the type being thrown with the type being caught. A
std::runtime_er ror *is* a std:exception -- all exception classes in
<stdexcept> are derived from std::exception. Hence the code I posted will
catch a std::runtime_er ror as well as any other std::exception.

However, this brings out an important point: if you write the catch phrase
as

catch (std::exception e)

the actual exception will be bit sliced down to a std::exception and the
polymorphic behavior will be lost.
Logic errors of the type traditionally represented by assertions should
derive from std::logic_erro r (if you want to use exceptions for this). I
would expect to find this sort of exception primarily in library code that
is intended to be widely reused and must perform parameter validation
without asserting.

Gregg


--
Cy
http://home.rochester.rr.com/cyhome/
Jul 23 '05 #5
Thanks for your respones ! I am more clear than before about
exceptions. The general idea I am getting is that exceptions must be
used very judiciously (for truly exceptional situations) because they
can be easily misused. For other cases, I will go with with the good
ol' assert (as I am developing a whole package instead of a generic
library).

Thanks,
Vijay.

Jul 23 '05 #6
GB
Cy Edmunds wrote:
"GB" <gb@invalid.inv alid> wrote in message
news:1E_Rd.1569 04$Jk5.141149@l akeread01...
Cy Edmunds wrote:
Just derive all of your exception classes from std::exception and this is
it! In principle you don't need to write any other try blocks in the
entire program. Can't get much simpler than that.
If you are going to use the standard library exception classes the way
they were intended, then errors that occur in the environment of the
program, such as user errors, device I/O errors, or resource errors,
should be derived from std::runtime_er ror, not std::exception.

You have confused the type being thrown with the type being caught. A
std::runtime_er ror *is* a std:exception -- all exception classes in
<stdexcept> are derived from std::exception. Hence the code I posted will
catch a std::runtime_er ror as well as any other std::exception.


I didn't confuse anything. You said "Just derive all of your exception
classes from std::exception" . This is not in general good advice. I know
how catching by reference polymorphically works. In fact that is why
advising to derive from std::exception is not good advice.
However, this brings out an important point: if you write the catch phrase
as

catch (std::exception e)

the actual exception will be bit sliced down to a std::exception and the
polymorphic behavior will be lost.


Yes, that is true, but I didn't see anyone suggest catching that way. In
your previous post you were catching (std::exception &) which is almost
correct. In general, you should catch by const reference where possible.

Gregg
Jul 23 '05 #7
"GB" <gb@invalid.inv alid> wrote in message
news:serSd.7867 $%U2.4464@laker ead01...
Cy Edmunds wrote:
"GB" <gb@invalid.inv alid> wrote in message
news:1E_Rd.1569 04$Jk5.141149@l akeread01...
Cy Edmunds wrote:
Just derive all of your exception classes from std::exception and this
is it! In principle you don't need to write any other try blocks in the
entire program. Can't get much simpler than that.

If you are going to use the standard library exception classes the way
they were intended, then errors that occur in the environment of the
program, such as user errors, device I/O errors, or resource errors,
should be derived from std::runtime_er ror, not std::exception.

You have confused the type being thrown with the type being caught. A
std::runtime_er ror *is* a std:exception -- all exception classes in
<stdexcept> are derived from std::exception. Hence the code I posted will
catch a std::runtime_er ror as well as any other std::exception.


I didn't confuse anything. You said "Just derive all of your exception
classes from std::exception" . This is not in general good advice.


With the code I posted it wouldn't be correct to say that one must use
std::runtime_er ror -- any std::exception will work. And using or deriving
from std::runtime_er ror *is* deriving from std::exception, consistent with
my advice.

Looking at it another way, I did NOT say to NOT use std::runtime_er ror as
the actual exception to be thrown.
I know how catching by reference polymorphically works. In fact that is
why advising to derive from std::exception is not good advice.
Huh?
However, this brings out an important point: if you write the catch
phrase as

catch (std::exception e)

the actual exception will be bit sliced down to a std::exception and the
polymorphic behavior will be lost.
Yes, that is true, but I didn't see anyone suggest catching that way. In
your previous post you were catching (std::exception &) which is almost
correct. In general, you should catch by const reference where possible.


Nonsense. An exception object needn't be protected using const for the
simple reason that the code which threw it has already been unwound. If the
catch phrase modifies it there can be no side effects. Hence the exception
belongs fully to the catch phrase which can do with as it pleases.

Gregg

Jul 23 '05 #8
GB
Cy Edmunds wrote:
"GB" <gb@invalid.inv alid> wrote in message
news:serSd.7867 $%U2.4464@laker ead01...
Cy Edmunds wrote:
"GB" <gb@invalid.inv alid> wrote in message
news:1E_Rd.1 56904$Jk5.14114 9@lakeread01...
Cy Edmunds wrote:

>Just derive all of your exception classes from std::exception and this
>is it! In principle you don't need to write any other try blocks in the
>entire program. Can't get much simpler than that.

If you are going to use the standard library exception classes the way
they were intended, then errors that occur in the environment of the
program, such as user errors, device I/O errors, or resource errors,
should be derived from std::runtime_er ror, not std::exception.
You have confused the type being thrown with the type being caught. A
std::runtime _error *is* a std:exception -- all exception classes in
<stdexcept > are derived from std::exception. Hence the code I posted will
catch a std::runtime_er ror as well as any other std::exception.
I didn't confuse anything. You said "Just derive all of your exception
classes from std::exception" . This is not in general good advice.

With the code I posted it wouldn't be correct to say that one must use
std::runtime_er ror -- any std::exception will work. And using or deriving
from std::runtime_er ror *is* deriving from std::exception, consistent with
my advice.

Looking at it another way, I did NOT say to NOT use std::runtime_er ror as
the actual exception to be thrown.

I know how catching by reference polymorphically works. In fact that is
why advising to derive from std::exception is not good advice.


Huh?


If you derive directly from std::exception, you have to either catch
your exception explictly, or catch all std::exception objects. You lose
the ability to catch your exception by catching only the
std::runtime_er ror subset.

However, this brings out an important point: if you write the catch
phrase as

catch (std::exception e)

the actual exception will be bit sliced down to a std::exception and the
polymorphi c behavior will be lost.


Yes, that is true, but I didn't see anyone suggest catching that way. In
your previous post you were catching (std::exception &) which is almost
correct. In general, you should catch by const reference where possible.

Nonsense. An exception object needn't be protected using const for the
simple reason that the code which threw it has already been unwound. If the
catch phrase modifies it there can be no side effects. Hence the exception
belongs fully to the catch phrase which can do with as it pleases.


No, it is not nonsense. If you don't catch by const reference, you will
fail to catch an exception that is a const object.

Gregg
Jul 23 '05 #9
>> Nonsense. An exception object needn't be protected using const for the
simple reason that the code which threw it has already been unwound. If
the catch phrase modifies it there can be no side effects. Hence the
exception belongs fully to the catch phrase which can do with as it
pleases.


No, it is not nonsense. If you don't catch by const reference, you will
fail to catch an exception that is a const object.

Gregg


Perhaps you could show a code example.
Jul 23 '05 #10

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

Similar topics

6
2098
by: Karl A. Krueger | last post by:
I'm in the middle of refactoring a small mod_python Web application, which uses the Publisher handler. This application is currently a single main Python file (which loads several other files as modules) with several function entry points for the different pages in the application. (The application is a tool to allow staff members here to request firewall port openings for their servers. Thus there is a page (and function) for "view...
11
2879
by: adi | last post by:
Dear all, This is more like a theoretical or conceptual question: which is better, using exception or return code for a .NET component? I had created a COM object (using VB6), which uses return code (not generating error/exception) so it is more compatible with other programming language.
7
6003
by: Noor | last post by:
please tell the technique of centralize exception handling without try catch blocks in c#.
13
3879
by: Markus Elfring | last post by:
Do you know a class library that can convert the error/return codes that are listed in the standard header file "errno.h" into a well-known exception hierarchy? Did anybody derive it from "std:runtime_error"? Regards, Markus
3
2749
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 ?
2
2594
by: tom | last post by:
Hi, I am developing a WinForm application and I am looking for a guide on where to place Exception Handling. My application is designed into three tiers UI, Business Objects, and Data Access Layer. My questions is where should I put exception handling: 1) Should it be put in all significant methods in all layers? 2) Should I create an exception base class that will handle the errors and pass useful error messages to the user?
9
2538
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...
44
4214
by: craig | last post by:
I am wondering if there are some best practices for determining a strategy for using try/catch blocks within an application. My current thoughts are: 1. The code the initiates any high-level user tasks should always be included in a try/catch block that actually handles any exceptions that occur (log the exception, display a message box, etc.). 2. Low-level operations that are used to carry out the high level tasks
1
3108
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
8792
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9293
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...
1
9064
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
9003
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7932
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
5941
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
4456
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
4713
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
2508
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

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.