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 _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison