Gherkin::Parser::ParsingError doesn't include the name or path of the file being parsed.

[mattwynne]

e.g. http://pastie.org/668021

[msassak]

ParsingError comes from the Ragel part of Gherkin, so think it makes more sense to add that information to the Cucumber code which instantiates the Gherkin parser and then calls the parser's #scan method. Something like:

gherkin_parser = Gherkin::Feature.new(lang, listener)
begin
  gherkin_parser.scan(input_string)
rescue ParsingError => e
  raise CucumberParsingError.new("/path/to/example.feature", e.line, e.content)
end

This way the Gherkin parser doesn't need any knowledge of the source of the input. Gherkin can also throw a FeatureSyntaxError on syntax errors. The difference between the two is that ParsingError means Ragel cannot recognize the input tokens, so it can't continue at all, whereas FeatureSyntaxError means the listener has received an event when it should not have, e.g. a py_string was encountered within an examples table. You can tell Gherkin not to raise a FeatureSyntaxError and send a syntax error message to the listener instead, but it's really impractical to even try to recover from a ParsingError, so that one is a full stop.

Thoughts?

[mattwynne]

Makes total sense.

I threw this together earlier on actually: http://github.com/mattwynne/cucumber/commit/e4ab3aa3c2adce3f1bf97cd4f406a533852e91b9

I guess we just need a feature or two for the gherkin parser integration in cucumber to drive this out?

[msassak]

Definitely. Also worth considering: adding an attribute writer on ParsingError (say "source") which would change the error message. That way clients of Gherkin can just add it if needed.

[aslakhellesoy]

How about just adding a scan_file method? That should do it for LexingError. The parser doesn't know about the file, but the lexer could intercept any ParseErrors and just add the file info before throwing it up.

Needs to be done in Ruby, C and Java

[msassak]

I'm not sure about the scan_file method. That seems to add the responsibility of knowing the execution environment into Gherkin, when it could be handled within Cucumber. Currently all the Gherkin lexer needs is a string--where that came from it does not care. If there is a lexing or parsing error, the gherkin parser plugin in Cucumber could catch it, add the info and then raise.

[aslakhellesoy]

Good point Mike. I'll close this then. No knowledge of source location in Gherkin.