joestelmach / natty

Java natural language date parser
http://natty.joestelmach.com/
MIT License
520 stars 183 forks source link

SLF4J for class DateParser_NumericRules #135

Open zakyvit opened 9 years ago

zakyvit commented 9 years ago

Hi,

I run my application on tomcat. This app uses natty date parser, and I have catalina.out file full of errors "natty line 0:-1 no viable alternative at input ''".

I found that DateParser_NumericRules hasn't displayRecognitionError method ovveriden. Could you add to the DateParser_NumericRules generator SLF4J logger?

Thanks

joestelmach commented 9 years ago

NumericRules.g is imported by DateParser.g, which does contain a displayRecognitionError implementation. I believe an additional override inside NumericRules would cause a compilation error.

Can you provide some sample inputs that invoke this error?

zakyvit commented 9 years ago

There are 2 problems: 1, As you said DateParser_NumericRules doesn't contain displayRecognitionError implementation, and I would welcome it if this class contains this implementation too.

Now if I run application with natty parser, then this class logs errors to catalina.out (using System.err.println(msg)), and I would welcome if this class logs errors with slf4j logger as other classes.

Temporarily I add this overriding method to the generated java class, compile it and add it to the jar library. And from now the errors are sent to the right logger.

2, My application parse something about 200 000 texts per day, therefore I have log full of this errors "natty line 0:-1 no viable alternative at input". I try to catch some examples, when this error appears.

vivekk0903 commented 6 years ago

This following sample program triggers the error message to System.error()

Parser parser1 = new Parser();
List<DateGroup> groups1 = parser1.parse("Diagnosis 1: AMS");

Here's the stack trace:

Thread [main] (Suspended (breakpoint at line 344 in BaseRecognizer))    
    DateParser_NumericRules(BaseRecognizer).emitErrorMessage(String) line: 344  
    DateParser_NumericRules(BaseRecognizer).displayRecognitionError(String[], RecognitionException) line: 194   
    DateParser_NumericRules(BaseRecognizer).reportError(RecognitionException) line: 186 
    DateParser_NumericRules(DebugParser).reportError(RecognitionException) line: 98 
    DateParser_NumericRules.int_00_to_59_mandatory_prefix() line: 606   
    DateParser.int_00_to_59_mandatory_prefix() line: 36814  
    DateParser.minutes() line: 33938    
    DateParser.explicit_time_hours_minutes() line: 33318    
    DateParser.explicit_time() line: 32799  
    DateParser.date_time() line: 1003   
    DateParser.date_time_alternative() line: 2380   
    DateParser.parse() line: 591    
    Parser.singleParse(TokenStream, String, Date) line: 201 
    Parser.parse(String, Date) line: 112    
    Parser.parse(String) line: 67   
    Test.main(String[]) line: 43    

I am using version 0.13 from maven.

vikramshrowty commented 4 years ago

My knowledge of ANTLR is very rudimentary but it looks like NumericRules.g generates DataParser_NumericRules.java , which is a standalone subclass of org.antlr.runtime.Parser and is missing the displayRecognitionError override.

I added the below to NumericRules.g and it compiled fine and stopped producing those messages. Not sure if this is the right thing to do, but if it is, I can submit a PR. @joestelmach : let me know

@parser::members {
  private static org.slf4j.Logger _logger =
    org.slf4j.LoggerFactory.getLogger(com.joestelmach.natty.generated.DateParser_NumericRules.class);

  @Override
  public void displayRecognitionError(String[] tokenNames, RecognitionException re) {
    String message = getErrorHeader(re);
    try { message += getErrorMessage(re, tokenNames); } catch(Exception e) {}
    _logger.debug(message);
  }
}