Lets say I have the following error string:
err = "/mnt/cd4/autorun.lua:43: 'end' expected (to close 'while' at line 1)
near '-eof-'"
How would I parse the file path, line number, and the error message separately from the string?
I have no prior experience in parsing Lua strings, so I thought asking here would be useful. I also tried finding a topic solving the same matter but I could not find one.
Something like this should work:
err = "/mnt/cd4/autorun.lua:43: 'end' expected (to close 'while' at line 1) near '-eof-'"
local file, line, errmsg = err:match('^(.-):(%d+):(.+)')
print(file, line, errmsg)
The pattern says: capture starting at the end of the line (^) a shortest group of zero or more (-) of any symbol (.), followed by :, then a group of one or more digits (%d+), followed by :, and then a group of one of more symbols (.+). You can read about patterns here.
Related
I am using ANTLR to parse a language which uses the colon for both a comment indicator and as part of a 'becomes equal to' assignment. So for example in the line
Index := 2 :Set Index
I need to recognize the first part as an assignment statement and the text after the second colon as a comment. Currently I do this using the rule:
COMMENT : ':'+ ~[:='\r\n']*;
This seems to work OK apart from when the colon is immediately followed by a new line. e.g. in the line
Index := 2 :
the newline occurs immediately after the second colon. In this case the comment is not recognized and the rest of the code is not parsed in the correct context. If there is a single space after the second colon the line is parsed correctly.
I expected the '\r'\n' to cope with this but it only seems to work if there is at least one character after the comment symbol - have I missed something from the command?
The braces denote a collection of characters without any quotes. Hence your '\r\n' literal doesn't work there (you should have got a warning that the apostrophe is included more than once in the char range.
Define the comment like this instead:
COMMENT: ':'+ ~[:=\n\r]*;
Select * from mytable where field=
'ce7bd3d4-dbdd-407e-a3c3-ce093a65abc9;cdb597073;7cf6cda5fc'
Getting Below Error while running above query in Hive
FAILED: ParseException line 1:92 character '' not supported here
<EOF> here means End Of File. When you get an "unexpected End Of File" error it means the parser reached the end of the query unexpectedly. This typically happens when the parser is expecting to find a closing character, such as when you have started a string with ' or " but have not closed the string (with the closing ' or ").
When you come across these types of errors it is good to check that your query can be parsed correctly. In addition, the error gives you the location where the parser failed: line 1:92 in this case. You can usually look at this location (character 92 of the query) and work backwards to find the problem character.
Try adding the database name to the "from" statement as below.
Select * from my_db_name.mytable where field= 'ce7bd3d4-dbdd-407e-a3c3-
ce093a65abc9;cdb597073;7cf6cda5fc';
Hive uses the default database when no database was previously specified.
I would like to be able to print this error message using Ragel
=> Parsing error found at position line:col, Integer expected instead.
Is that possible with Ragel?
Best regards
I haven't gotten too far into error handling in Ragel just yet, but I would expect that if you use the error action embedding operators as specified in section 3.2.3 of the Ragel 6.9 Guide, that would override the default message.
You can get the line number by incrementing a counter at each newline, and get the column by taking the current position and subtracting the position of the previous newline, something like this:
newline = '\n' %{ ++lineCounter; linePosition = p; }
action ErrorHandler {
column = p - linePosition + 1;
// Print error message here using lineCounter and column
}
main := (allsortsofstuff | newline)* <>err(ErrorHandler);
Of course, the above may require a bit of tweaking based on exactly what you're doing, but at least it's a starting point.
I got this error message while using StringTemplate:
line 94:26: unexpected char: ')'
And after about 15 minutes of randomly adding and removing blank lines in my template, and observing how the number in that message changed, I finally isolated the line that caused trouble. It was line #152, position #35.
Is the value after "line " just normally totally wrong, or is there a way of deducing the real line number from that output?
In StringTemplate (ST) 4, it appears that the first number is the line number, within the specific template at issue and not the line number within the .stg file if that's what you're using (which most of us do).
When I'm using vim, this means I need to mentally offset that from the line number of the first line of the template (add them together) to get the actual line number within the .stg file.
The second number in the ST error is the character position within that line of the template. But wait, there's more - you know you love it...
When an error is on the first line of a multi-line template: since ST elides the starting newline in multi-line templates, ST effectively combines the first/ declaration line (ending in "<<") with the second (actual start of the template) line, in multi-line templates;
so at least with ST-4.0.8 I need to subtract the length of the template declaration line from the character position, to get the actual character position.
The first "\n" eliding (for multi-line templates only) also means the line number may appear to be offset by 1, and possibly the character position, for an error on the "first line".
The error should include the filename and template name, so it's enough information for an automated script or tool, but a bit cumbersome for us mere humans.
Good luck.
ANTLR gives me the following error when my input file has either no newline at the EOF, or more than one.
line 0:-1 mismatched input '' expecting NEWLINE
How would I go about taking into account the possibilities of having multiple or no newlines at the end of the input file. Preferably I'd like to account for this in the grammar.
The rule:
parse
: (Token LineBreak)+ EOF
;
only parses a stream of tokens, separated by exactly one line break, ending with exactly one line break.
While the rule:
parse
: Token (LineBreak+ Token)* LineBreak* EOF
;
parses a stream of tokens separated by one or more line breaks, ending with zero, one or more line breaks.
But do you really need to make the line breaks visible in the parser? Couldn't you put them on a "hidden channel" instead?
If this doesn't answer your question, you'll have to post your grammar (you can edit your original question for that).
HTH