Boost logo

Boost :

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-10-12 11:10:42

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>

> Yes, and that idiom is so useful that Boost.Test provides library code to
> handle the details.
> > You can do the
> >same thing in other functions that you don't want anything to escape
> >from (e.g. destructors, extern "C" functions that will be used as
> >callbacks, etc). If you can't rely on everything having std::exception
> >in its family tree, you have to either use catch (...), which denies
> >you the chance of logging any meaningful error message, or write a
> >whole stack of catch clauses for every exception you can think of.
> >
> >I'd like to suggest (to the Boost readership in general) that this
> >should be made a requirement for all Boost libraries.
> I agree, unless there is some application specific reason why another
> approach is better.

It is understandable that in standard C++, it is easy to have situations
where exceptions are unhandled. Usually, the trigger and the
handler are miles apart. Often times, a specific library throws
an exception and it is up to the client to handle this.

This is certainly not the case with Spirit. Thus, I take exception
to this rule that you wish to impose. In Spirit, there is always
a handler for every trigger. In addition, the declarative nature
of Spirit-ish EBNF makes this easy to spot. The trigger (parser
assertion) is declared somewhere very close to the handler
(the guard). Consider a rule that handles unpaired parenthesis:

    group = '(' >> expression >> expect(')');
    factor = integer | group;
    term = factor >> *(('*' >> factor) | ('/' >> factor));
    expression = term >> *(('+' >> term) | ('-' >> term));
    start = expr_guard(expression)[handle_invalid_espression];

Here, expect(')') throws an exception when a close paranthesis
is not found. This exception is caught by expr_guard and is
handled by handle_invalid_espression.

... I still assert that we should not force libraries to follow a
canonical form. We can never be sure if such rules will apply
to *all* libraries. In the case of Spirit, I don't see how
deriving from the std exceptions will benefit the library
or the library users. In fact, it will just add a virtual table and
possibly a char const* or a std::string to the parser exception
which will be wasted and unused.


Boost list run by bdawes at, gregod at, cpdaniel at, john at