Hi Akim,
if I might chime in here:
Looking at the generated lalr1 parser, it contains the code (shortened here in
this email)
> catch (...) {
> if (!yyla.empty ()) yy_destroy_ (YY_NULLPTR, yyla);
> while (1 < yystack_.size ()) {
> yy_destroy_ (YY_NULLPTR, yystack_[0]);
> yypop_ ();
> }
> throw;
> }
which catches all exceptions and cleans up before rethrowing them.
This block seems to be missing in glr.cc (I didn't actually check the generated
code, just had a look at the skeleton file, so maybe I am missing something
here)
So, a non-syntax_error exception would bubble up through the GLR parser and
could be caught outside the parser, just like in the LALR1 parser.
However, such an exception would leave the parser in a dirty state instead of
doing the necessary cleanup.
@Askar: please correct me if I misunderstood the issue
Cheers,
Adrian
On 02/01/2019, 12:12, "bison-patches on behalf of Akim Demaille"
<[email protected] on behalf of
[email protected]> wrote:
Hey Askar,
> Le 2 janv. 2019 à 01:49, Askar Safin <[email protected]> a écrit :
>
> Also, I looked into generated .tab.cpp files and saw that LALR1 parser
have "catch (...)" and GLR parser doesn't have "catch (...)". So, it seems GLR
parser will support syntax_error exceptions only, but not all other exceptions
(i. e. GLR parser will not rethrow non-syntax_error exceptions correctly,
unlike LALR1 parser).
Your sentence is confusing. It seems you are saying that the other
exceptions will be blocked, which is of course not what is going to happen.
> And this is _very_ strange.
Less than this comment :)
> At least user should be warned about such very strange behavior in docs.
Contributions are most welcome. As always.
