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++. 11 3238
"Master of C++" <ma*************@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.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 "programming 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/
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_error, not std::exception. Logic
errors of the type traditionally represented by assertions should derive
from std::logic_error (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 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_error,
not std::exception. Exception classes representing logic errors of the
type traditionally represented by assertions should derive from
std::logic_error (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
"GB" <gb@invalid.invalid> wrote in message
news:1E_Rd.156904$Jk5.141149@lakeread01... 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_error, 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_error 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_error (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/
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.
Cy Edmunds wrote: "GB" <gb@invalid.invalid> wrote in message news:1E_Rd.156904$Jk5.141149@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_error, 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_error 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
"GB" <gb@invalid.invalid> wrote in message
news:serSd.7867$%U2.4464@lakeread01... Cy Edmunds wrote: "GB" <gb@invalid.invalid> wrote in message news:1E_Rd.156904$Jk5.141149@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_error, 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_error 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_error -- any std::exception will work. And using or deriving
from std::runtime_error *is* deriving from std::exception, consistent with
my advice.
Looking at it another way, I did NOT say to NOT use std::runtime_error 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
Cy Edmunds wrote: "GB" <gb@invalid.invalid> wrote in message news:serSd.7867$%U2.4464@lakeread01...
Cy Edmunds wrote:
"GB" <gb@invalid.invalid> wrote in message news:1E_Rd.156904$Jk5.141149@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_error, 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_error 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_error -- any std::exception will work. And using or deriving from std::runtime_error *is* deriving from std::exception, consistent with my advice.
Looking at it another way, I did NOT say to NOT use std::runtime_error 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_error 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 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.
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
>> 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.
Cy Edmunds wrote: 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.
If I did, it would only demonstrate that I was wrong :-). Furthermore,
in an attempt to demonstrate how modifying an exception object in a
handler could cause a side effect, I learned of another misconception I
had. I thought the following code would print 2 instead of 1:
#include <iostream>
int e = 1;
int main()
{
try {
throw e;
} catch (int& e) {
++e;
}
std::cout << e << std::endl;
}
Both gcc 3.3 and Visual C++ 2005 beta print 1. Apparently a copy of the
exception object is made even if it is caught by reference. I did not
know this.
Gregg
* Cy Edmunds -> Gregg B: Looking at it another way, I did NOT say to NOT use std::runtime_error as the actual exception to be thrown.
There is an issue here relating to "soft" versus "hard" exceptions; the
same issue reflected by the division of the exception class hierarchy in
some other languages such as Java and C#.
Catching std::exception in the 'main' function is OK. Catching std::exception
at lower levels might run the risk of catching e.g. std::bad_alloc (or worse).
Yes, mostly one does not care what exception is caught, mostly all exceptions
are in practice equal, but some are more equal than others...
However, as with many in things in C++ it's all about convention, and if there
isn't a reasonable convention being rigorously followed then what you do or
don't do doesn't matter: the non-conforming code makes all efforts
at sane exception handling moot (in my humble opinion). I know how catching by reference polymorphically works. In fact that is why advising to derive from std::exception is not good advice.
Huh?
I gather he's referring to what I tried to sketch above: if even _one_ "soft"
exception class is derived directly from std::exception then that might
necessitate catching std::exception instead of std::runtime_error at low
levels, rendering a convention designed to let through "hard" exceptions
impotent. 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.
Well, for standard exceptions:
* Not using const indicates that there is an intent to modify.
On the other hand, some non-standard exceptions such as MFC exceptions must
be modified by the handler.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
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...
|
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...
|
by: Noor |
last post by:
please tell the technique of centralize exception handling without try catch
blocks in c#.
|
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...
|
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...
| |
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...
|
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...
|
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...
|
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{
|
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,...
|
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...
| |
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,...
|
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...
|
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...
|
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...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
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...
| |