How to tell if an exception has currently been thrown and is beingprocessed ?

[Timothy Madden]

Hello

What is the function that could tell if there is an exception currently
being thrown, that is causing stack unwinding ? I guess it was a
function returning true during unwinding and false otherwise.

Also, is there a way to get the current exception object (other then as
the argument to the catch handler) ?

Is there a way to store or keep the exception object (and its type) for
later processing outside of the handler or the try-catch function that
caught it ?

Thank you,
Timothy Madden

 

[Goran Pusic]

Hello

What is the function that could tell if there is an exception currently
being thrown, that is causing stack unwinding ? I guess it was a
function returning true during unwinding and false otherwise.

uncaught_exception, perhaps?

Also, is there a way to get the current exception object (other then as
the argument to the catch handler) ?

Well, what's wrong with the catch itself? If you want to inspect
somehow your exception while it unwinds, it's sufficient to catch it,
read it, then re-throw it.

Is there a way to store or keep the exception object (and its type) for
later processing outside of the handler or the try-catch function that
caught it ?

AFAIK, no. I'd try employing "cloneable" interface and clone the
exception from the catch.

class /*interface*/ i_cloneable { virtual base* clone(); }
base* p = NULL;
try
{
}
catch(const exception& e)
{
i_cloneable* original = dynamic_cast<i_cloneable*>(&e);
if (original)
p = original->clone();
else
p = clone_of(e); // Exercise for the reader. ;-)
}

Goran.

P.S. Obviously, your post begs a MASSIVE "why do you think you need
this?" 'Cause you do not seem to use exceptions the way they are meant
to be used (as seen by your need to "see" them outside the catch).
Normally, only place where you do not have an anonymous exception
object is said catch. And that goes for many other languages, C++ is
not special in this respect. Chances are, you are doing something
wrong.

 

[Timothy Madden]

Hello

What is the function that could tell if there is an exception currently
being thrown, that is causing stack unwinding ? I guess it was a
function returning true during unwinding and false otherwise.

uncaught_exception, perhaps?

Also, is there a way to get the current exception object (other then as
the argument to the catch handler) ?

Well, what's wrong with the catch itself? If you want to inspect
somehow your exception while it unwinds, it's sufficient to catch it,
read it, then re-throw it.

Is there a way to store or keep the exception object (and its type) for
later processing outside of the handler or the try-catch function that
caught it ?

[...]
P.S. Obviously, your post begs a MASSIVE "why do you think you need
this?" 'Cause you do not seem to use exceptions the way they are meant
to be used (as seen by your need to "see" them outside the catch).
Normally, only place where you do not have an anonymous exception
object is said catch. And that goes for many other languages, C++ is
not special in this respect. Chances are, you are doing something
wrong.

I use minizip package from zlib-1.2.5 to unpack an archive from my
client's web server given by the URL. zlib uses callbacks for file io
(open, read, write, seek, tell, close, error) functions, that
application will provide and that I will define to eventually
read/write/seek from a CHttpFile.

The problem is CHttpFile and other code in the callbacks have the habit
of throwing exceptions, which I can not let propagate to the
minizip/zlib code invoking them, as that code is written in C and is not
exception-safe. So I have a need to catch the exceptions in the
read/write callbacks, and throw them again when control reaches back my
application, which can handle exceptions and knows what to do with them.

So in short I need to store the exception for processing at a later
time, i.e. out of the callback and within application code.

I think the same requirements hold true for any sort of callback
functions, including callbacks passed to Windows API functions, unless
the invoker specifies it is exception-safe.

Thank you,
Timothy Madden

 

[Alf P. Steinbach /Usenet]

* Timothy Madden, on 31.08.2010 15:25:

Hello

What is the function that could tell if there is an exception currently
being thrown, that is causing stack unwinding ? I guess it was a
function returning true during unwinding and false otherwise.

uncaught_exception, perhaps?

Also, is there a way to get the current exception object (other then as
the argument to the catch handler) ?

Well, what's wrong with the catch itself? If you want to inspect
somehow your exception while it unwinds, it's sufficient to catch it,
read it, then re-throw it.

Is there a way to store or keep the exception object (and its type) for
later processing outside of the handler or the try-catch function that
caught it ?

[...]
P.S. Obviously, your post begs a MASSIVE "why do you think you need
this?" 'Cause you do not seem to use exceptions the way they are meant
to be used (as seen by your need to "see" them outside the catch).
Normally, only place where you do not have an anonymous exception
object is said catch. And that goes for many other languages, C++ is
not special in this respect. Chances are, you are doing something
wrong.

I use minizip package from zlib-1.2.5 to unpack an archive from my client's web
server given by the URL. zlib uses callbacks for file io (open, read, write,
seek, tell, close, error) functions, that application will provide and that I
will define to eventually read/write/seek from a CHttpFile.

The problem is CHttpFile and other code in the callbacks have the habit of
throwing exceptions, which I can not let propagate to the minizip/zlib code
invoking them, as that code is written in C and is not exception-safe. So I have
a need to catch the exceptions in the read/write callbacks, and throw them again
when control reaches back my application, which can handle exceptions and knows
what to do with them.

So in short I need to store the exception for processing at a later time, i.e.
out of the callback and within application code.

I think the same requirements hold true for any sort of callback functions,
including callbacks passed to Windows API functions, unless the invoker
specifies it is exception-safe.

This is pretty simple to do. Just catch the exceptions and return an error
indication up through the C code or set a static variable. You can choose to
either just generate new exceptions at the C++ app layer, or clone the originals.

There's no need to check for exceptions in stack unwinding (that would mean, in
some destructor).

Besides, Visual C++ probably still does not implement uncaught_exception.


Cheers & hth.,

- Alf

 

[Anthony Williams]

So in short I need to store the exception for processing at a later
time, i.e. out of the callback and within application code.

I think the same requirements hold true for any sort of callback
functions, including callbacks passed to Windows API functions, unless
the invoker specifies it is exception-safe.

You need the C++0x std::exception_ptr support. std::current_exception
captures the currently-being handled exception when used inside a catch
block, and then std::rethrow_exception allows that exception to be
rethrown later.

g++ 4.4 and later in -std=c++0x mode and MSVC2010 support
std::exception_ptr.

My thread library implementation (http://www.stdthread.co.uk) provides
full std::exception_ptr support for MSVC 2005 and 2008, and basic
support (i.e. for standard-library exceptions) for g++ 4.3.

Anthony

 

[Goran Pusic]

I use minizip package from zlib-1.2.5 to unpack an archive from my
client's web server given by the URL. zlib uses callbacks for file io
(open, read, write, seek, tell, close, error) functions, that
application will provide and that I will define to eventually
read/write/seek from a CHttpFile.

The problem is CHttpFile and other code in the callbacks have the habit
of throwing exceptions, which I can not let propagate to the
minizip/zlib code invoking them, as that code is written in C and is not
exception-safe. So I have a need to catch the exceptions in the
read/write callbacks, and throw them again when control reaches back my
application, which can handle exceptions and knows what to do with them.

So in short I need to store the exception for processing at a later
time, i.e. out of the callback and within application code.

I think the same requirements hold true for any sort of callback
functions, including callbacks passed to Windows API functions, unless
the invoker specifies it is exception-safe.

Whoops! That is a __perfectly__ good reason. (Blushes, thinks "Why
didn't I think of that!?")

But! But.. That said (and, we're off-topic now), you are in the luck!
Because these MFC classes will throw exceptions by pointer, and you
can easily store it and use it elsewhere! E.g.

rettype zlib_callback(params p)
{
try
{
OperateOnMfcStuff();
}
catch(CException* p)
{
get_app_specific_data(p).mfcException = p; // You win!
}
}

Just don't use MFC exception handling macros and don't forget to
eventually call Delete() (not "delete p") on said exception pointer
( but I guess you already know this ;-) ).

Goran.

P.S. I can't effin' __believe__ that MFC has finally shown itself more
appropriate than what you would do with "normal" C++ code!

 

[Timothy Madden]

Hello

What is the function that could tell if there is an exception currently
being thrown, that is causing stack unwinding ? I guess it was a
function returning true during unwinding and false otherwise.

uncaught_exception, perhaps?

Also, is there a way to get the current exception object (other then as
the argument to the catch handler) ?

Well, what's wrong with the catch itself? If you want to inspect
somehow your exception while it unwinds, it's sufficient to catch it,
read it, then re-throw it.

Is there a way to store or keep the exception object (and its type) for
later processing outside of the handler or the try-catch function that
caught it ?

[...]
P.S. Obviously, your post begs a MASSIVE "why do you think you need
this?" 'Cause you do not seem to use exceptions the way they are meant
to be used (as seen by your need to "see" them outside the catch).
Normally, only place where you do not have an anonymous exception
object is said catch. And that goes for many other languages, C++ is
not special in this respect. Chances are, you are doing something
wrong.

I use minizip package from zlib-1.2.5 to unpack an archive from my
client's web server given by the URL. zlib uses callbacks for file io
(open, read, write, seek, tell, close, error) functions, that
application will provide and that I will define to eventually
read/write/seek from a CHttpFile.

The problem is CHttpFile and other code in the callbacks have the habit
of throwing exceptions, which I can not let propagate to the
minizip/zlib code invoking them, as that code is written in C and is not
exception-safe. So I have a need to catch the exceptions in the
read/write callbacks, and throw them again when control reaches back my
application, which can handle exceptions and knows what to do with them.

So in short I need to store the exception for processing at a later
time, i.e. out of the callback and within application code.

I think the same requirements hold true for any sort of callback
functions, including callbacks passed to Windows API functions, unless
the invoker specifies it is exception-safe.

Thank you all for your answers. I think I will need to catch for some
possible exception types and store the exception in a union or
boost::variant if I want to still have an idea of the exception type
when I re-throw.

I was asking here to see if there is some more generic way to store the
exception regardless of its type. And indeed there is one, except that
it is in a rather draft stage and I need the new Visual Studio 2010 to
get it.
(my company has Visual Studio 2008...)

Thank you,
Timothy Madden

 

[Goran Pusic]

Thank you all for your answers. I think I will need to catch for some
possible exception types and store the exception in a union or
boost::variant if I want to still have an idea of the exception type
when I re-throw.

Multiple exception hierarchy roots are PITA. If possible, it's IMO
preferable to have one base exception class.

If so, you don't need variant. In particular, since you're in MFC
already, just use CException everywhere (or at least, for everything
MFC-specific). That's what I do when in MFC.

Goran.