|
Boost : |
From: williamkempf_at_[hidden]
Date: 2001-08-03 11:05:14
--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
>
> > > > I've considered including a thread::exit() routine,
> > > > but don't expect one in the first release.
> > >
> > > hmm.. why not static void thread::exit( ..<return value>.. )
> > > that would simply throw some termination exception which
> > > you would catch in your internal bootstrap routine?
> >
> > Simply because it's not safe.
> >
> > void foo()
> > {
> > try
> > {
> > bar();
> > }
> > catch (...)
> > {
> > // Log that an error occured.
> > }
> > }
> >
> > void bar()
> > {
> > thread::exit();
> > }
> >
> > > that exception could carry the reason (normal exit
> > > or cancellation) and return value to be made available
> > > for join (in the case of thread cancellation, posix join
> > > returns PTHREAD_CANCELED pointer).
> >
> > Other libraries have tried to do this with exceptions, and the
above
> > code points out the hole in the concept. At first you might think
> > that you can simply avoid catch(...) in your thread code, but if
your
> > thread code calls library routines that include catch(...)
blocks...
>
> ...how about something like:
>
> class auto_rethrow_exception {
> public:
>
> auto_rethrow_exception() :
> m_rethrow( 1 )
> {
>
> cout << this << " ctor" << endl;
>
> }
>
> ~auto_rethrow_exception()
> {
>
> cout << this << " dtor" << endl;
>
> if ( m_rethrow ) {
>
> cout << "re-throw..." << endl;
>
> m_rethrow = 0;
>
> throw auto_rethrow_exception();
>
> }
>
> }
>
> void catched()
> {
>
> cout << this << " catched()" << endl;
>
> m_rethrow = 0;
>
> }
>
> private:
>
> int m_rethrow;
>
> };
>
> int main()
> {
>
> try {
>
> try {
>
> throw auto_rethrow_exception();
>
> }
> catch(...) {
>
> cout << "catch(...)" << endl;
>
> }
>
> }
> catch( auto_rethrow_exception& ex ) {
>
> cout << "catched!" << endl;
>
> ex.catched();
>
> }
>
> cout << "done" << endl;
>
> return 0;
>
> }
>
> MS Visual C++ 6.0:
>
> 0x0012FF64 ctor
> catch(...)
> 0x0012FF68 dtor
> re-throw...
> 0x0012F980 ctor
> catched!
> 0x0012F984 catched()
> 0x0012F984 dtor
> done
>
> IBM VisualAge C++ 3.5:
>
> 0x12ff78 ctor
> catch(...)
> 0x12ff78 dtor
> re-throw...
> 0x12fa08 ctor
> catched!
> 0x12fa08 catched()
> 0x12fa08 dtor
> 0x12ff78 dtor
> done
>
> regards,
> alexander.
A good attempt at bypassing the problem, but it doesn't cover all the
basis. This *ISN'T* really an exception but instead is an attempt at
program flow control. The problem is that code can still catch these
exceptions, even if you insure they are rethrown. Imagine, for
example, a catch block coded as:
try
{
}
catch(...)
{
LogError();
exit();
}
The programmer probably doesn't want LogError() called for this non-
error, and he definately doesn't want the program to exit.
Bill Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk