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

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-10-12 07:06:21

----- Original Message ----- 
From: "Ross Smith" <r-smith_at_[hidden]>

> On Saturday, 12 October 2002 18:28, Joel de Guzman wrote:
> > 
> > From: "Carl Daniel" <cpdaniel_at_[hidden]>
> >
> > > Exception classes thrown by Spirit (parser_error<>,
> > > illegal_backtracking) don't derive from std::exception - shouldn't
> > > they?
> >
> > I'm not sure. Should it? What will be the benefits in doing so?
> > The truth is, I'm not quite happy with the standard C++ exceptions.
> > For one, it's hard coded the what() to be a string.
> 
> The big advantage of requiring all exceptions to be derived from 
> std::exception, as I see it, is that you can write your main function 
> like this...
> 
>     int main() {
>       try {
>         // code goes here
>         return 0;
>       }
>       catch (const std::exception& ex) {
>         std::cerr << "*** " << ex.what() << "\n";
>         return EXIT_FAILURE;
>       }
>     }
> 
> ...and be confident of getting an error message instead of a crash if 
> anything gets thrown that you haven't explicitly caught. 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.

Well, I am perfectly aware of that. However, if that's the only rationale,
what you are suggesting is something I definitely would not agree on.
First of all, the use of exceptions in Spirit is paired. Parser assertions
are always caught by the guard. It makes no sense to write parser
assertions without guards. Yet, if this is the intent of the programmer,
I have to trust her 100%.

Regards,
--Joel