Bill,

the try { throw; } idiom is a great way to centralize exception
type-detection (e.g. for reporting) code, but you're right that MSVC has a
problem with multiple destruction in this case. That's I always make sure my
exception classes are resilient to multiple-destruction when targeting MSVC.

-Dave

----- Original Message -----
From: <williamkempf@[...]..> 
To: <boost@[...].com> 
Sent: Tuesday, February 13, 2001 4:57 PM
Subject: [boost] Re: Review: Boost Test Library


>  Just a thought to spark others creativity...
> 
>  I've been thinking a bit about the desire for catch_exceptions() to
>  be able to handle registered exception types (during my breaks from
>  documenting the BTL, which should be done in a day or two for those
>  who are helping me finalize this before submitting), and a trick
>  suggested on a programming site I read in the past came to mind
>  (sorry, I can't give exact credit here). Error handling functions
>  can be registered and called from catch blocks by using the following
>  idiom:
> 
>  bool handle_my_error_types()
>  {
>  try
>  {
>  throw; // re-throw the last exception
>  }
>  catch (my_specific_error_type err)
>  {
>  // handle the error
>  return true; // we handled the error
>  }
>  catch (...)
>  {
>  return false; // we didn't handle the error
>  }
>  }
> 
>  void example()
>  {
>  try
>  {
>  // some code that throws
>  }
>  catch (...)
>  {
>  if (handle_my_error_types())
>  cout << handled << endl;
>  else
>  cout << unknown exception type << endl;
>  }
>  }
> 
>  I think that this idiom could be used to allow test programs
>  to push handlers for specific exception types that they used onto
>  a handler stack that would be used by catch_exceptions(). This
>  should allow for very specific reports about what exceptions are
>  caught by the test framework, even though the framework is not aware
>  of library defined exception types.
> 
>  The one caveat is that (at the time I found this idiom at least) VC++
>  couldn't handle this (it tries to destruct the exceptions multiple
>  times!).
> 
>  Any thoughts or comments on the idea?
> 
>  Bill Kempf
> 
> 
> 
>