[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exception safety of generated C++ parser
From: |
Oleksii Taran |
Subject: |
Re: Exception safety of generated C++ parser |
Date: |
Fri, 28 Sep 2012 23:42:28 +0300 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 |
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
- Re: Exception safety of generated C++ parser, (continued)
- Re: Exception safety of generated C++ parser, Akim Demaille, 2012/09/19
- Re: Exception safety of generated C++ parser, Oleksii Taran, 2012/09/19
- Re: Exception safety of generated C++ parser, Akim Demaille, 2012/09/20
- Re: Exception safety of generated C++ parser, Oleksii Taran, 2012/09/20
- Re: Exception safety of generated C++ parser, Akim Demaille, 2012/09/21
- Re: Exception safety of generated C++ parser, Oleksii Taran, 2012/09/24
- Re: Exception safety of generated C++ parser, Akim Demaille, 2012/09/24
- Re: Exception safety of generated C++ parser, Akim Demaille, 2012/09/26
- Re: Exception safety of generated C++ parser,
Oleksii Taran <=
- Re: Exception safety of generated C++ parser, Oleksii Taran, 2012/09/28