Re: [boost] Do we need a boost_exception class or idiom?

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-20 14:24:13

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>; "Boost mailing list"
<boost_at_[hidden]>
Sent: Wednesday, November 20, 2002 3:43 PM
Subject: Re: [boost] Do we need a boost_exception class or idiom?

> At 01:20 PM 11/20/2002, Fernando Cacciola wrote:
>
>  >I'm not sure if a boost exception class is *needed*, but I see no
problem
>
>  >in
>  >having one.
>  >Anyway, IIF such an exception class is defined, I *strongly* encourage
> (as
>  >I
>  >did in the past) that it provides:
>  >
>  >  virtual void raise() const
>  >  {
>  >    #ifndef BOOST_NO_EXCEPTIONS
>  >      throw *this ;
>  >    #endif
>
> My naive expectation would be to call abort() if not wishing to handle
> exceptions,
I agree... I just omitted the #else part :-)

> but that really is a side issue. The bigger issue is whether or
> not Boost should have a usual way of defining error exceptions thrown by
> Boost libraries, with raise() being one of the issues to be dealt with.
>
> [snipped]
>
>I'm not sure if what we need is a class, a concept, or just some
>documentation.

Me neither... And I agree we should explore the big picture first.

I can start with the rationale behind 'raise()', at least, which shows that
it is not about 'raise' itself, specifically, but about encapsulation.

The common idiom:

   if ( error )
     throw some_exception("....");

is not sufficiently encapsulated for library-code.
The problems are:
  (1) is disseminated along tons of code.
  (2) a throw expression is typically complex in terms of machine code, so
it usually spoils inlining.
  (3) has no application-level control

Error handling is one of the most typical library aspects that applications
need to customize.
I've turned down otherwise excellent libraries just because they have fixed
(even if very good for a specific context) error handling.

So, my first conclusion is that as a minimum, users will benefit if we
encapsulate error handling in ways that users can hook into.

BOOST_ASSERT, is IMO, starting off in the right direction in this respect.

Perhaps some sort of BOOST_ERROR macro which encapsulates a concept in a way
similar to BOOST_ASSERT might also work.

Fernando Cacciola