Good morning, Paul D. DeRocco,

Paul D. DeRocco schrieb:

>>""Daniel Kr=FCgler (ne Spangenberg)"" <dsp@bdal.de> wrote
>>
>>Actually I never needed such a clone facility for exception functions. =
I
>>don't think, that your proposed
>>rethrow() is necessary, because the language has provided a mechanism
>>for the discussed situation:
>>
>>    try {
>>        ...
>>        }
>>    catch (const exception& x) {
>>            // Do what you need to do and deligate:
>>            throw; // Rethrows the original exception
>>        }
>>   =20
>>
>
>But that's not the situation I'm talking about. I'm talking about rethro=
wing
>the exception _outside_ the catch block. By that point, you can only use
>"throw x;", not "throw;", so the type of the rethrown exception is the
>static type of x, not the original dynamic type of the exception.
>
>I realize this isn't a common situation, but it's come up for me, in the
>context of a file system that did overlapped I/O using a separate disk
>access thread. I needed to save a clone of an exception detected by the =
disk
>access thread, and rethrow it in the applicaton thread.
>

Aaah, I see that I misunderstood your question and I understand now why=20
you are asking for that
virtual cloning facility.  But I assume, that the requirement for=20
rethrow() is actually not necessary, provided you
have invented your own exception hierachy. In that case you could=20
seperate the context information from
your exception classes and the only thing you need for rethrowing is a=20
virtual exception_context class, which
allows virtual coning of itself. In that case you can always "rethrow"=20
an instance of the one-and-only-one
exception (base) class with different context information contents.

Hope that helps,

Daniel


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > Actually I never needed such a clone facility for exception functions. I
> > don't think, that your proposed
> > rethrow() is necessary, because the language has provided a mechanism
> > for the discussed situation:
> >
> >     try {
> >         ...
> >         }
> >     catch (const exception& x) {
> >             // Do what you need to do and deligate:
> >             throw; // Rethrows the original exception
> >         }
>
> But that's not the situation I'm talking about. I'm talking about rethrowing
> the exception _outside_ the catch block. By that point, you can only use
> "throw x;", not "throw;", so the type of the rethrown exception is the
> static type of x, not the original dynamic type of the exception.
>
> I realize this isn't a common situation, but it's come up for me, in the
> context of a file system that did overlapped I/O using a separate disk
> access thread. I needed to save a clone of an exception detected by the disk
> access thread, and rethrow it in the applicaton thread.

Exactly it's this kind of situations where I once wanted such an interface, too.
My personal application was a C++ function similar to POSIX "pthread_once()".
The signature looks as follows:

template< class Op >
void thrdOnce(volatile thrdOnce_tWrapperfacade &,Op);

where "Op" can both be a function pointer or a function object (derived
from "std::unary_function< void,void >"). I don't want to discuss the nonportable
implementation of "double checked locking" here, but one question remains:
How to react upon an exception thrown by the function (object)? This exception
can be caught by the thread that by accident has called the function (object)
supplied. The other threads must wake up even then not to block infinitely - and
they can be informed about the failure by a flag stored in "thrdOnce_tWrapperfacade",
which has been set within the catch-block by the thread that called the function (object).

For symmetry reasons it was nice if all threads - regardless of whether they actually
have called the function (object) or not - could rethrow the exception the function
(object) has thrown. Currently, with "throw;" this is only possible for the thread, that
accidently caught the exception, which would impose some unsymmetry and uncover
the information, which threads did what, to the caller.

Another way only possible with the virtual "clone()" member function was to encapsulate
the exception into proxy exceptions, which are the ones that get thrown by each
individual thread that has called "thrdOnce()".

Cheers,
Philipp.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> ""Daniel Kr   gler (ne Spangenberg)"" <dsp@bdal.de> wrote
>
> Actually I never needed such a clone facility for exception functions. I
> don't think, that your proposed
> rethrow() is necessary, because the language has provided a mechanism
> for the discussed situation:
>
>     try {
>         ...
>         }
>     catch (const exception& x) {
>             // Do what you need to do and deligate:
>             throw; // Rethrows the original exception
>         }

But that's not the situation I'm talking about. I'm talking about rethrowing
the exception _outside_ the catch block. By that point, you can only use
"throw x;", not "throw;", so the type of the rethrown exception is the
static type of x, not the original dynamic type of the exception.

I realize this isn't a common situation, but it's come up for me, in the
context of a file system that did overlapped I/O using a separate disk
access thread. I needed to save a clone of an exception detected by the disk
access thread, and rethrow it in the applicaton thread.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

These would be useful virtual member functions for exceptions.

Currently, there is no coherent way to save an exception inside a catch
block, and then check it later, because the exception object disappears when
the catch block is exited. Unfortunately, you can't really copy the
exception either, because any copy you make will only be of the static type
caught by the catch block, not the actual dynamic type. What's needed is a
way to clone the object, using a virtual function defined in the dynamic
type:

    exception* saved_x;

    try {
        ...
        }
    catch (const exception& x) {
        saved_x = x.clone();
        }

Of course, one of the things one might like to do with such a saved
exception would be to rethrow it. There, again, one would like the proper
dynamic type to be thrown, which can't be done by writing "throw *saved_x;".
Instead, you'd need a virtual "rethrow" function:

    saved_x->rethrow();

I've implemented these functions for my own exception classes, but I have to
check explicitly for the language-defined exceptions (bad_alloc, etc.), and
for the RTL exceptions derived from runtime_error and logic_error, and
handle them specially.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Good morning, Paul D. DeRocco,

Paul D. DeRocco schrieb:

>These would be useful virtual member functions for exceptions.
>
>Currently, there is no coherent way to save an exception inside a catch
>block, and then check it later, because the exception object disappears =
when
>the catch block is exited. Unfortunately, you can't really copy the
>exception either, because any copy you make will only be of the static t=
ype
>caught by the catch block, not the actual dynamic type. What's needed is=
 a
>way to clone the object, using a virtual function defined in the dynamic
>type:
>
>    exception* saved_x;
>
>    try {
>        ...
>        }
>    catch (const exception& x) {
>        saved_x =3D x.clone();
>        }
>
>Of course, one of the things one might like to do with such a saved
>exception would be to rethrow it. There, again, one would like the prope=
r
>dynamic type to be thrown, which can't be done by writing "throw *saved_=
x;".
>Instead, you'd need a virtual "rethrow" function:
>
>    saved_x->rethrow();
>
>I've implemented these functions for my own exception classes, but I hav=
e to
>check explicitly for the language-defined exceptions (bad_alloc, etc.), =
and
>for the RTL exceptions derived from runtime_error and logic_error, and
>handle them specially.
>

Actually I never needed such a clone facility for exception functions. I=20
don't think, that your proposed
rethrow() is necessary, because the language has provided a mechanism=20
for the discussed situation:

    try {
        ...
        }
    catch (const exception& x) {
            // Do what you need to do and deligate:
            throw; // Rethrows the original exception
        }


Hope that helps,

Greetings from Bremen,

Daniel Kr=FCgler


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]