C++ Exception handling

[junw2000]

Is C++ Exception handling useful? think it is too complicated. What
kinds of project need to use it? Thanks.

 

[Neil Cerutti]

Is C++ Exception handling useful? think it is too complicated. What
kinds of project need to use it? Thanks.

The feature itself isn't that complicated, it's just using them
correctly that is hard. They are rather like a unicycle in that way.

When designing objects with contructors that might fail, exceptions
become quite useful. The other option is to return invalid objects and
hope nobody uses them.

 

[Roland Pibinger]

Is C++ Exception handling useful? think it is too complicated.

Exception handling combined with RAII (the most important C++ idiom)
greatly simplifies programming. In C++ exception handling is
complicated only if you disregard RAII and try to use it in
Java-style.

What kinds of project need to use it?

All except 'Hello world'.

Best wishes,
Roland Pibinger

 

[Michael Redlich]

Is C++ Exception handling useful? think it is too complicated. What
kinds of project need to use it? Thanks.

Yes, the C++ exception handling mechanism is extremely useful.

It is a more robust method for handling errors than fastidiously
checking for error codes from functions that return 0 on success, and
some non-zero value on failure. This kind of error code checking is
tedious and obscures your program logic.

The C++ Exception Model:
* destructors are invoked for all live objects as the stack of function
calls "unwinds."
* exception specifications specify what type of exception(s) a function
will throw.
* termination vs. resumption semantics.

I wouldn't consider exception handling too complicated. You need to
understand:
* the syntax to implement.
* what happens when an exception is thrown.
* how to handle the exception.

Hope this helps...

Mike

 

[Gavin Deane]

The C++ Exception Model:
* destructors are invoked for all live objects as the stack of function
calls "unwinds."
* exception specifications specify what type of exception(s) a function
will throw.

Unfortunately, that's not quite what exception specifications do, since
there's no way in general for the exception specification to be
enforced by the compiler. They are generally regarded as the one part
of C++ exception handling that is largely useless.

http://www.gotw.ca/gotw/082.htm
http://www.boost.org/more/lib_guide.htm#Exception-specification

Gavin Deane

 

[Roland Pibinger]

Unfortunately, that's not quite what exception specifications do, since
there's no way in general for the exception specification to be
enforced by the compiler.

Unlike Java, C++ exception specification are supposed to be enforced
by _you_, the programmer, not the compiler. You (can) guarantee that
only the specified exception(s) may be thrown from a function.

They are generally regarded as the one part
of C++ exception handling that is largely useless.

Nope, they are useful especially for high level functions and
interfaces. They tighten the 'contract' between implementor and user.
They are just not like Java exception specifications.

http://www.gotw.ca/gotw/082.htm
http://www.boost.org/more/lib_guide.htm#Exception-specification

Stroustrup "The C++ Programming Language" 14.6

Best wishes,
Roland Pibinger

 

[Gavin Deane]

Unlike Java, C++ exception specification are supposed to be enforced
by _you_, the programmer, not the compiler. You (can) guarantee that
only the specified exception(s) may be thrown from a function.

I (can) also make mistakes.

Nope, they are useful especially for high level functions and
interfaces. They tighten the 'contract' between implementor and user.

How? Since the exception specification is not enforced by the compiler,
how is it anything more than documentation of what the function is
supposed to do?

If the function really will only ever throw the specified exceptions,
then moving the exception specification from the documentation to the
code adds nothing.

Gavin Deane

 

[Roland Pibinger]

How? Since the exception specification is not enforced by the compiler,

They are enforced in the code by the implementor. That's the point.
The user can rely on the exception specification.

how is it anything more than documentation of what the function is
supposed to do?

If your exception specification is not correct then it's a bug in your
code (that probably crashes the program). That's much more than 'just'
documentation. BTW, if you know which exception can be thrown you can
specifiy it in code _and_ documentation. If you don't know you can do
neither.

Best wishes,
Roland Pibinger

 

[Gavin Deane]

They are enforced in the code by the implementor. That's the point.
The user can rely on the exception specification.

If some behaviour is only enforced in the code by the implementor, then
anything that communicates the nature of that behaviour to other
programmers is documentation. C++ provides a tool for that - comments.

If your exception specification is not correct then it's a bug in your
code (that probably crashes the program).

Or it's a bug in the exception specification itself. If I modify the
implementation of a function so that instead of, for example, doing all
its processing in memory, it temporarily reads and writes to a file,
but I fail to add my file IO exception to the documentation, one of two
things could happen. If I have documented the exceptions thrown by
writing a comment then I have confused maintenance programmers (a bad
thing). If I have documented the exceptions thrown by writing an
exception specification then I have broken the program (a worse thing).

The use of exception specifications has made my program more brittle.

That's much more than 'just'
documentation. BTW, if you know which exception can be thrown you can
specifiy it in code _and_ documentation. If you don't know you can do
neither.

I don't think writing the documentation in two places is a good idea.

Gavin Deane

 

[Martin Aupperle]

Is C++ Exception handling useful? think it is too complicated. What
kinds of project need to use it? Thanks.

"Too complicated" compared to what? All alternatives that can solve
the same problem as the exception concept are more complicated, clumsy
etc.

Please do not compare a program that uses EH with one that doesn't.

Martin

 

[Marcus Kwok]

Unfortunately, that's not quite what exception specifications do, since
there's no way in general for the exception specification to be
enforced by the compiler. They are generally regarded as the one part
of C++ exception handling that is largely useless.

http://www.gotw.ca/gotw/082.htm
http://www.boost.org/more/lib_guide.htm#Exception-specification

Here's another article that basically summarizes to "Don't use exception
specifications":

http://www.gotw.ca/publications/mill22.htm

 

[Geo]

If your exception specification is not correct then it's a bug in your
code (that probably crashes the program). That's much more than 'just'
documentation. BTW, if you know which exception can be thrown you can
specifiy it in code _and_ documentation. If you don't know you can do
neither.

But int the presence of function objects, call back functions,
polymorphism or templates, it's almost impossible to make your
exception specifications correct, and therefore almost guaranteeing
that your program *will* crash.

 

[Roland Pibinger]

But int the presence of function objects, call back functions,
polymorphism or templates, it's almost impossible to make your
exception specifications correct, and therefore almost guaranteeing
that your program *will* crash.

You mean you cannot safely write a function that complies to an
exception specification?

void foo() throw (MyException) {
try {

// use function objects, call back functions,
// polymorphism or templates


} catch (MyException& e) {
throw;
} catch (std::exception& e) {
throw MyException (e);
} catch (...) {
throw MyException ("unknown exception in foo()");
}
}

For a generalized 'ExceptionFilter' see
http://article.gmane.org/gmane.comp.lib.boost.devel/132551

Best wishes,
Roland Pibinger

 

[Geo]

You mean you cannot safely write a function that complies to an
exception specification?

void foo() throw (MyException) {
try {

// use function objects, call back functions,
// polymorphism or templates


} catch (MyException& e) {
throw;
} catch (std::exception& e) {
throw MyException (e);
} catch (...) {
throw MyException ("unknown exception in foo()");
}
}

For a generalized 'ExceptionFilter' see
http://article.gmane.org/gmane.comp.lib.boost.devel/132551

Best wishes,
Roland Pibinger

But what would be the point of that, you've just localised the
exception handling, destroying the real advantage of exceptions
(dealing with them at the most appropriate level) just to satisfy a
pointless exception spec. It would have been much cleaner and less
error prone to just have omitted the exception spec. How useful is
you're 'unknown' exception, after all the original exception probably
was/is known, just not to you're catch block, lost information for no
gain.