librelist archives

« back to archive

Error handling for semantic actions

Error handling for semantic actions

From:
Johannes Emerich
Date:
2011-05-13 @ 16:16
Hey everyone,

in the process of adding helpful error information to my Java compiler I
noticed that errors occuring in semantic actions do not get handled by
the `parseError` function. Given its name, this makes perfect sense.

But since nowhere in the parser there is anything catching the error, it
bubbles up, aborting the `parse` function. I can catch it there, but by
then much of the useful information (e.g. line number) is lost.
Looking at the parser source code, there is currently no possibility to
prevent this (right?).

In January Yehuda Katz wrote in an answer to the announcement of the
availability of the Bison Location API[1], that he'd use the API to
improve debugging information of handlebars.js. I browsed the repo, but
couldn't find any use of the API yet. Did you ever get to implement your
plans, Yehuda?
The way I read Yehuda's message, he intended to pass the location info
to the AST node constructors as arguments. Is that correct?

I wonder if it wouldn't be easier to incorporate some kind of error
handling into the parser, such that errors in semantic actions are
caught, augmented with context information from the parser and then
re-thrown. Similar to the `parseError` function, this could optionally
be replaced with a custom function.

Let me know, what you think.

Thanks and kind regards,
Johannes

[1] 
http://librelist.com/browser//jison/2011/1/22/bison-location-api-implemented/#b931ea33799faf98fe2a22db731be00d

Re: [jison] Error handling for semantic actions

From:
Zachary Carter
Date:
2011-05-14 @ 19:59
On Fri, May 13, 2011 at 12:16 PM, Johannes Emerich <johannes@emerich.de> wrote:
> Hey everyone,
>
> in the process of adding helpful error information to my Java compiler I
> noticed that errors occuring in semantic actions do not get handled by
> the `parseError` function. Given its name, this makes perfect sense.
>
> But since nowhere in the parser there is anything catching the error, it
> bubbles up, aborting the `parse` function. I can catch it there, but by
> then much of the useful information (e.g. line number) is lost.
> Looking at the parser source code, there is currently no possibility to
> prevent this (right?).
>
> In January Yehuda Katz wrote in an answer to the announcement of the
> availability of the Bison Location API[1], that he'd use the API to
> improve debugging information of handlebars.js. I browsed the repo, but
> couldn't find any use of the API yet. Did you ever get to implement your
> plans, Yehuda?
> The way I read Yehuda's message, he intended to pass the location info
> to the AST node constructors as arguments. Is that correct?
Yes. Like this:
https://github.com/zaach/reflect.js/blob/master/lib/grammar.y#L43

>
> I wonder if it wouldn't be easier to incorporate some kind of error
> handling into the parser, such that errors in semantic actions are
> caught, augmented with context information from the parser and then
> re-thrown. Similar to the `parseError` function, this could optionally
> be replaced with a custom function.
>
> Let me know, what you think.

You'd probably only want this while you are developing your parser, so
it's sensible to add it as a debug mode feature (pass the -t optional
argument to jison for debug mode.) Another thing I plan to add is full
tracing of the parse.

It should be enough to re-throw the error with context information as
you suggest, using a try catch around the semantic action function
call. It's a little different from parseError because the error
doesn't happen at a specific token, but after they have all been
parsed.

I'm not sure what you mean by a 'custom function'. Couldn't you catch
the error in your code?


>
> Thanks and kind regards,
> Johannes
>
> [1] 
http://librelist.com/browser//jison/2011/1/22/bison-location-api-implemented/#b931ea33799faf98fe2a22db731be00d
>


Thanks,
Zach Carter



-- 
Zach Carter

Re: [jison] Error handling for semantic actions

From:
Johannes Emerich
Date:
2011-05-16 @ 11:20
Hi Zach!

>> The way I read Yehuda's message, he intended to pass the location info
>> to the AST node constructors as arguments. Is that correct?
> Yes. Like this:
> https://github.com/zaach/reflect.js/blob/master/lib/grammar.y#L43

Thanks! That's how I thought it may be done, but was hoping there'd be
a way to do it without having to manually push the loc parameter(s) as
an argument on every node creation. I have now understood that not
saving the location information in the respective nodes, though, would
allow for only the most basic of location information. (For example it
is very easy to modify the parser to provide location information for
the previous token, but most compilers provide much more reasonable
information (e.g. location of operator instead of last operand).)

>> I wonder if it wouldn't be easier to incorporate some kind of error
>> handling into the parser, such that errors in semantic actions are
>> caught, augmented with context information from the parser and then
>> re-thrown. Similar to the `parseError` function, this could optionally
>> be replaced with a custom function.
>> 
>> Let me know, what you think.
> 
> You'd probably only want this while you are developing your parser, so
> it's sensible to add it as a debug mode feature (pass the -t optional
> argument to jison for debug mode.) Another thing I plan to add is full
> tracing of the parse.

Tracing would be great! As for location-augmented re-throwing, after
understanding its limits, I am not sure it's a useful addition at
all. What do you really think? I'd be happy to contribute an
implementation in case the feature makes sense for Jison.

> It should be enough to re-throw the error with context information as
> you suggest, using a try catch around the semantic action function
> call. It's a little different from parseError because the error
> doesn't happen at a specific token, but after they have all been
> parsed.

I'm not sure if I understand you correctly. As I understand the code,
the semantic actions are being executed in the reduce part of the
parser-loop (i.e., when there is no further recursing down the
sub-tree). So you probably mean that the error happens after all
tokens in a subtree have been parsed? Or do I have some kind of
misconception here?

> I'm not sure what you mean by a 'custom function'. Couldn't you catch
> the error in your code?

Since I don't intend to implement recovery from any errors thrown at
this point, yes, that's much better. I'm not sure if there is really
a scenario for recovery.

Thanks for your help!

Best,
Johannes