TITLE: NOTES FROM ANSI/ISO - CLARIFICATIONS ON EXCEPTION HANDLING

Issue #021
March, 1997


Contents:

Pointers to Members
A New Angle on Function Pointers
Notes From ANSI/ISO - Clarifications on Exception Handling
Introduction to STL Part 8 - advance() and distance()


POINTERS TO MEMBERS

 [snip]

A NEW ANGLE ON FUNCTION POINTERS

 [snip]

NOTES FROM ANSI/ISO - CLARIFICATIONS ON EXCEPTION HANDLING
Jonathan Schilling, jls@sco.com

The ANSI/ISO C++ standards meeting earlier this month in Nashua, New
Hampshire, produced some clarifications of exception handling
semantics.

One interesting case is this one, which was featured in the January
1997 issue of the magazine C++ Report:

        try {
                // exception prone code here, that may do a throw
        }
        catch (...) {
                // common error code here
                
                try {
                        throw;  // re-throw to more specific handler
                }
                catch (ExceptA&) {
                        // handle ExceptA here
                }
                catch (ExceptB&) {
                        // handle ExceptB here
                }
                catch (...) {
                        // handle unknown exceptions here
                }

                throw;
        }

The idea behind the code is to factor out common error handling logic 
into the first part of the catch handler (so as not to replicate it), 
rethrow the exception to get error handling specific to the exception 
in the individual inner handlers, and then finally to rethrow the 
exception again to let functions further up the call chain do their 
handling.

The question is, does this code work as intended?  The draft standard
speaks of a throw creating a temporary object that is then deleted when
the corresponding handler exits.  Does this mean that when the inner
handlers above exit, the rethrow will be of a nonexistent temporary
object?  The standard isn't really clear on this, and some existing 
compilers have been found to do the deletion at the inner handler,
with the result that the program crashes.

The answer is that this code should indeed work as intended, and that
the existing compilers for which this does not work are wrong.
(Fortunately SCO's new C++ compiler is one of the ones that is getting
it right!).
 
Furthermore, the committee stated that the value of the standard library 
function uncaught_exception() (see C++ Newsletter #019) changes (from 
false to true) at both of the rethrows, until such time as the rethrown
exception is caught again.

Another exception handling issue that was clarified is whether base
class destructors are called when a derived class destructor throws an 
exception:
                
        class B {
        public:
                ~B() { ... }
        };

        class D : public B {
        public:
                ~D() { throw "error"; }
        };

        void f() {
                try {
                        D d;
                }
                catch (...) { }
        }

Does ~B() get called as well as ~D()?  The answer is yes.  This may 
seem almost obvious -- it is part of the general principle of C++
that constructed subobjects always get destroyed if something goes
wrong with the enclosing object -- but in fact there was some debate
on this within the committee.

Finally, one of the comments from the ANSI public review period
concerned an area of exception handling that needed no clarification
but is often misunderstood:

        try {
                throw 0;
        }
        catch (void *) {
                // does the exception get caught here?
        }

The handler should not catch the exception, but apparently in some
compilers it does.  The draft standard is clear that throw and catch
types either have to match exactly, or be related by inheritance, or
be subject to a pointer-to-pointer standard conversion.  Since 0 is
not of a pointer type, the last requirement isn't met, and no handler
is found.  Similarly note that the whole range of other standard
conversions do not apply, so that for example a handler of type long
does not catch an exception of type int.

INTRODUCTION TO STL PART 8 - ADVANCE() AND DISTANCE()

 [snip]

ACKNOWLEDGEMENTS

Thanks to Nathan Myers, Eric Nagler, David Nelson, and Jonathan
Schilling for help with proofreading.


SUBSCRIPTION INFORMATION / BACK ISSUES

To subscribe to the newsletter, send mail to majordomo@world.std.com
with this line as its message body:

subscribe c_plus_plus

Back issues are available via FTP from:

        rmi.net /pub2/glenm/newslett

or on the Web at:

        http://rainbow.rmi.net/~glenm

There is also a Java newsletter.  To subscribe to it, say:

subscribe java_letter

using the same majordomo@world.std.com address.

-------------------------

Copyright (c) 1997 Glen McCluskey.  All Rights Reserved.

This newsletter may be further distributed provided that it is copied
in its entirety, including the newsletter number at the top and the
copyright and contact information at the bottom.

Glen McCluskey & Associates
Professional C++ Consulting
Internet: glenm@glenmccl.com
Phone: (800) 722-1613 or (970) 490-2462
Fax: (970) 490-2463
FTP: rmi.net /pub2/glenm/newslett (for back issues)
Web: http://rainbow.rmi.net/~glenm