Re: [boost] Re: Formal Review: The Spirit Parser Framework.

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.

Regards,
--Joel