I've defined the structure of an exception log entry, but how do I know that this is an exception and not a normal log entry? So far they both look the same: they both have timestamp, and they both span across one or more lines. To a human it's a rather obvious difference, and you immediately spot the exception, but are there any other fingerprints in the exception stack trace that I could use to identify it as a genuine exception and not the lengthy log entry?
If you look and compare different exception stack traces you'll notice one commonality: each exception stack trace mentions the exception class name. Some examples include org.xml.sax.SAXParseException and java.io.FileNotFoundException. This occurs because each exception is effectively an instance of the exception class. Again, class name could be anything, but it is an accepted practice to append the word "Exception to the class name. So I'm going to use this as one of my classifiers. Another classifier is the word java. Because I'm dealing with Java programs in most cases I will have one or more methods from native Java libraries. So I'm going to work on the assumption that if my exception candidate contains these two words, it is likely to be an actual exception. But I don't want to be limiting myself, so I have to make sure that my application structure allows me to change or plug in another validation method.
Now I have something to operate on—I know how my log entries should look. I also know what the exception looks like, as well as what makes it different from the normal log entry. That should be enough to implement the log parser.
Was this article helpful?