473,573 Members | 2,492 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 3257
"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
2089
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...
11
2851
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
5977
by: Noor | last post by:
please tell the technique of centralize exception handling without try catch blocks in c#.
13
3862
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
2740
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...
2
2587
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...
9
2529
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...
44
4186
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,...
1
3095
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
7747
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...
0
7670
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...
0
7987
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. ...
1
7740
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...
1
5557
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
3706
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...
0
3703
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
1269
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
1005
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...

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.