Exception handling questions

[Gonçalo Rodrigues]

Hi all,

I've got two somewhat general questions related to exception handling
in C++. My usual programming language is the lovely and flexible
Python, but for various reasons, including the need to interface with
third-party libraries, get extra performance, etc. I have to use C++.

Now in Python, being a dynamically typed language, everything is
pushed to the run-time. Additionaly, since the language does not
guarantee deterministic destruction of objects, there are try/finally
blocks everywhere and the release of resources is done *explicitly*.

In C++, the mindset is different. As far as I have managed to learn,
there are two grand rules to pay attention to:

- Use exceptions for run time conditions, assert's for
logical/programmer errors.

- Use RAII (resource acquisition is initialization) .

Is there any other big rule that I am missing?

As I have said earlier, one of the reasons I use C++ is when I have to
squeeze out more performance and optimizing the Python code is just
not enough. This leads me to my second question: what is the "penalty"
for using exceptions in C++? I just want to have an idea of the cost
in terms of space/time, an idea of "what to expect in general" when
using exceptions.

With my best regards,
G. Rodrigues

[Cy Edmunds]

"Gonçalo Rodrigues" <op*****@mail.t elepac.pt> wrote in message
news:8i******** *************** *********@4ax.c om...

Hi all,

I've got two somewhat general questions related to exception handling
in C++. My usual programming language is the lovely and flexible
Python, but for various reasons, including the need to interface with
third-party libraries, get extra performance, etc. I have to use C++.

Now in Python, being a dynamically typed language, everything is
pushed to the run-time. Additionaly, since the language does not
guarantee deterministic destruction of objects, there are try/finally
blocks everywhere and the release of resources is done *explicitly*.

In C++, the mindset is different. As far as I have managed to learn,
there are two grand rules to pay attention to:

- Use exceptions for run time conditions, assert's for
logical/programmer errors.

- Use RAII (resource acquisition is initialization) .

Is there any other big rule that I am missing?
I have no idea how to answer this question. The usual error for C++ newbies
is probably to use operator new way too much. I suppose this afflicts Java
programmers more than Python programmers. One thing to remember is that C++
classes are not automatically polymorphic as Python classes are. You have to
use the keyword "virtual" to get polymorphic behavior. There are too many
other differences to enumerate here.

I will suggest this though: use C++ standard library constructs such as
std::string and std::vector rather than the old C constructs of char* and
array. Effective usage of the standard library is what separates good from
bad C++ programmers IMHO. Plus it's easier.

As I have said earlier, one of the reasons I use C++ is when I have to
squeeze out more performance and optimizing the Python code is just
not enough. This leads me to my second question: what is the "penalty"
for using exceptions in C++? I just want to have an idea of the cost
in terms of space/time, an idea of "what to expect in general" when
using exceptions.
Exceptions are not expensive if you use them as they are meant to be used:
for exceptional situations. If you use them as control structures you can
run up a bill. I happened to be reading the Python cookbook last night and
saw a claim that using exceptions in Python to check things (in this case
whether a string contained a valid integer value) was highly pythonic. Such
uses are not typical in C++. However, using them for error handling is not
expensive and highly Bjarnic (a name I made up but which hasn't caught on
yet :).

One way or another, derive your exceptions from std::exception. I got into
an argument with someone on this point recently who insisted that it's a
mistake not to derive from std::runtime_er ror. Since one is derived from the
other I don't feel that strongly about it. std::runtime_er ror takes a string
argument which is convenient for error messages.

One other thing: C++ has a throw specification you can use in your
declarations such as:

void func() throw(); // promises not to throw any exceptions

I advise you not use them. If they did what they seem to promise they would
be useful, but they don't. For instance, the actual implementation of func()
may actually throw and everything compiles fine. :P

With my best regards,
G. Rodrigues

--
Cy
http://home.rochester.rr.com/cyhome/

[GB]

Cy Edmunds wrote:

One way or another, derive your exceptions from std::exception. I got into
an argument with someone on this point recently who insisted that it's a
mistake not to derive from std::runtime_er ror. Since one is derived from the
other I don't feel that strongly about it. std::runtime_er ror takes a string
argument which is convenient for error messages.

That would have been me.

I was not insisting it is a mistake. I was merely indicating the
intended use of the standard exception classes. The standard library
divides (most) exceptions at the top level into runtime errors and logic
errors. If you don't want to fit your exception into one of these two
categories, then by all means derive directly from std::exception.

Gregg

[Matt Bitten]

--- Gonçalo Rodrigues wrote:

In C++, the mindset is different. As far as I have managed to
learn, there are two grand rules to pay attention to:
And many others, I'm afraid. Any generally good programmer who
wants to start writing quality C++ code ought to get "Effective
C++" and "More Effective C++", by Scott Meyers. Get the CD
version, that has it all in HTML. There you'll find some 85
Rules to Live By. (Or, some say, 85 Reasons to Hate C++. You
can choose whichever spin you prefer.)

--- Cy Edmunds wrote: I happened to be reading the Python cookbook last night and
saw a claim that using exceptions in Python to check things (in
this case whether a string contained a valid integer value) was
highly pythonic.
Yep. And of course checking for end-of-container [in C++:
.... != container.end()] is usually done with exceptions in Python.
However, using them for error handling is not expensive and highly
Bjarnic (a name I made up but which hasn't caught on yet :).
No, it hasn't. I was going to prove you wrong, so I googled and
found exactly one other usage of the term. On dBforums. By you.
We'll see what we can do to get this term into mainstream usage.

BTW, I'm feeling rather Bjarnic today.
C++ has a throw specification you can use in your
declarations such as:

void func() throw(); // promises not to throw any exceptions

I advise you not use them. If they did what they seem to promise
they would be useful, but they don't.

I agree with your advice, but I would be careful with them even if
they worked as promised (is that an un-Bjarnic thought?). Do you
really want a "please crash" statement in release code? I don't.
Here is a safe way to use an exception spec:

void func()
#ifndef NDEBUG
throw()
#endif
; // The legendary "Lone Semicolon", defender of good syntax