Re: [boost] Exception handling - reprise

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-04 12:59:33

----- Original Message -----
From: "Giovanni Bajo" <giovannibajo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, June 03, 2002 7:02 PM
Subject: [boost] Exception handling - reprise

> Hello,
>
> There were some talks some time ago about introducing a new macro
> (BOOST_NO_EXCEPTIONS or something) to completely disable any kind of
> exception support from Boost (mainly due to performance issues on several
> compilers). This macro might be defined from within the compiler config
> headers where it's possible to autodetect if exceptions are disabled, or
> specified manually by the user on command line whenever he needs it. I
> certainly am not Boost-expert enough to do this, but I'd be grateful if
> someone could work on it before 1.29.
>
> Thanks
> Giovanni Bajo
>
I'm not sure how far library code can be implemented without exceptions -and
without changing the interface-.

A framework that at least can allow library code to retain exception-based
error managment uniformly, and still compile and run on exception-less
enviroments, is the following:

Use ONLY custom exception classes with an extended interface with a member
function 'raise()':

namespace boost {

  class logic_error : public std::logic_error
  {
      public :

         logic_error( string const& what ) : std::logic_error(what) {}

        void raise()  ;
  } ;

  void logic_error::raise()
  {
#ifndef     BOOST_NO_EXCEPTIONS
  throw *this ;
#else
  do something else...
#endif
   }
}

On this framework, exceptions are never thrown directly, but indirectly as
in:

  if ( some_error )
     boost::logic_error("whatever").raise();

This way, exception-less environments are not handled directly by the
library code.

The boost exception hierarchy can be implemented such that
'boost::exception' allows the user to register an error_handler for
non-exception environments.

I personally think that in this case, the non-exception 'raise' should call
the user provided error handler (if any) AND abort the application.
That is, this scheme is supposed to isolate from the library code the fact
that a target environment doesn't support exceptions, but retaining the
exception-based error logic. If a particular library code does know how to
be reliable without exceptions then it should do so in its own way -whatever
that can be-

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com