Re: [c++-pthreads] Re: thread-safety definition

[Wil Evers <wil@xxxxxxxxxxxxxx>]

Dave Butenhof wrote:

> But I think I also understand what you mean; 
> and the problem isn't with the model, but rather with the effect of that 
> model on existing code that all-too-casually and agressively eats 
> exceptions it doesn't understand. I think there are vanishingly few 
> circumstances where a blind catch(...) without an unconditional re-throw 
> should be considered "legitimate". If you don't completely understand 
> what an exception means, you cannot claim to have completely recovered, 
> and therefore cannot reasonably finalize propagation. (And when you 
> catch anonymously, you can't possibly understand what they mean since 
> you can't even identify them.) 

Let me try again.

Doing a blind catch(...) without an unconditional rethrow is not always 
a matter of sloppiness.  Sometimes, the only alternative is a crash - 
the C++ standard clearly says that a second exception escaping from a 
destructor invoked by the stack unwinding machinery will result in 
program termination.  There is nothing the poor programmer can do about 
this.

To reiterate: a few days ago, I posted the following example -

  remote_resource_holder::~remote_resource_holder()
  {
    remote_resource->release();
  }

Now what do you suggest I should do when an exception (say, a networking 
error, but it might just as well be a cancellation request) is thrown 
from somewhere within remote_resource->release()?  The way I see it, 
either the original exception or the one that was just thrown at me will 
have to be finalized.

- Wil