Re: Exception safety of generated C++ parser

[Oleksii Taran]

26.09.12 10:20, Akim Demaille wrote:
> Hi Oleksii,
>
> Le 24 sept. 2012 à 16:55, Akim Demaille a écrit :
>
>> The more I think about it, the more I believe that I took the wrong
>> path, and exception safety should be addressed at the yyparse level:
>> put the whole function into a try/catch block.  That way, we are
>> also protected from errors in %printer, %destructor, %initial-action,
>> yyerror, and maybe other places I didn't think about.  I will provide
>> another patch in the near future.
> There is a second branch, maint-exception-safety-2, that implements
> that.  I'd be interested in feedback.  In particular if someone has
> an opinion on which approach is the best one.
>
> I don't enforce exception safety when an exception is thrown from
> a %destructor: currently it results in an exception being thrown
> while another one is already in flight (because when we catch an
> exception, even thrown from a %destructor, we will clean the
> stack, which will certainly call again the bad %destructor).
>
> In that situation I could not clean the stack and lookahead.
>
> I'd rather make clear (in the documentation) that %destructors
> must not throw exception, just like for genuine C++ destructors.
> In master I'm getting to a point where the %destructors would
> serve to generate a real C++ destructor for the "symbol" objects,
> that wrap kind/value/location together.  So the C++ rule would
> simply apply to Bison's symbol: don't throw on destruction.
>

This approach looks more consistent for me. It may be more error-proof
and maintainable, and 'no-throw-in-destructor' rule is really reasonable.
I've tested it, and it seems to be equally good to
maint-exception-safety branch.

-- 
Best regards,
Oleksii Taran