Re: unexpected exception handler
"George" <George@discussions.microsoft.com> wrote in message
news:7B351A53-4DBC-43ED-874C-C073E038B899@microsoft.com
This question is about when it is allowed to call throw to re-throw
exception -- make the exception re-throw.
I can only think of two situations,
1. in catch block of an exception;
2. in unexpected handler.
Any function can contain a "throw;" statement. Such a function can be
called from a catch clause (or from unexpected() handler), directly or
indirectly:
void rethrow() { throw; }
try {...}
catch (const exception&) { rethrow(); }
If "throw;" statement is encountered while no exception is caught, the
program calls terminate().
For (2), in unexpected handler, since the input parameter is null, so
in order to get the exception information, we need to re-throw it and
catch it to get exception informaiton.
Is my understanding correct?
Sounds about right.
Here is some pseudo code from Bjarne's
book.
[Code]
// suppose throwY is unexpcted handler
void throwY() throw (Yunexpected)
{
try{
throw; // have to re-throw and catch in order to get exception
information since current input parameter is null and has no exception
information, my understanding correct?
} catch (Network_exception& p)
{
throw (Yunexpected (&p));
I wonder if this is going to work. An exception is a temporary object.
You are saving an address of a temporary, but I strongly suspect
Network_exception object will be destroyed as soon as throwY exits (by
throwing another exception), at which point your Yunexpected instance
will hold a dangling pointer. Unless of course Yunexpected's constructor
allocates a copy of its parameter on the heap and saves a pointer to
that copy, or otherwise extracts and saves off some information from its
parameter before it's destroyed.
} catch (...)
{
throw (Yunexpected (0));
}
}
[/Code]
Note that you've entered unexpected() handler in the first place because
some function has thrown an exception that wasn't on its exception
specification list. Your handler throws another exception, Yunexpected.
At this point, one of three things can happen:
a) the function's exception specification lists Yunexpected. In this
case, execution continues as if the function had thrown Yunexpected from
the beginning.
b) the function's exception specification doesn't list Yunexpected, but
does list std::bad_exception. In this case, execution continues as if
the function had thrown bad_exception
c) Neither Yunexpected nor bad_exception are listed in the function's
exception specification. In this case, the program calls terminate().
This means that, since the point of throwY handler seems to be to
convert all unexpected exceptions to Yunexpected wrapper, every function
in your program that has exception specification at all should mention
Yunexpected in it. Otherwise your handler is pointless.
Finally, it should be noted that many (most?) C++ experts believe that
exception specifications, as specified in the C++ standard, are a
mistake and should not be used. See for example
http://www.gotw.ca/publications/mill22.htm
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925