views:

410

answers:

3

I have been trying to parse Java exceptions that appear in a log for some code I'm working with. My question is, do you parse the exception trace from the top down, or the bottom up? It looks something like this:

ERROR [main]</b> Nov/04 11:03:19,440 [localhost].[/BookmarksPortlet].[] - Exception sending context...
org.springframework.beans.factory.BeanCreationException: Error creating bean...: Cannot Resolve reference...: Error creating bean... nested exception... nested exception is org.hibernate.HibernateException: Dialect class not found: org.hibernate.dialect.Oracle10gDialect
Caused by:
... [similar exceptions and nested exceptions]
...
    at [start of stack trace]

Something like that. Obviously, I'm not looking for the answer to this specific exception, but how do you go about parsing an exception trace like this? Do you start at the top level error, or do you start at the inner most error (under the "caused by" clauses)?

The problem is more difficult for me because I'm not working with code I wrote. I'm editing the XML configurations, so I'm not really even looking the Java code. In my own code, I would recognize locations in the trace and would know what sort of things to look for. So how do you approach an exception like this in general?

+2  A: 

This stuff is a little hard to explain, but my first step is nearly always starting from the top and skimming down until I see the familiar com.mycompany.myproject.

Given the line number attached to that you have a place to work from in your own code, which is often a good start.

Edit: But, re-reading your question you say it's not your code.. so this may not be a useful answer at all..

SCdF
Yeah, the stack trace is great in my own code, because I see the call stack and get some great info. But in this case, the code should be ok. I did something to the configuration that caused the exception, and I don't know where to start tracing.
Sam Hoice
+1  A: 

In your particular example, there's a class missing. As soon as you see an error like that, you know what needs fixing (either correcting the class name, or updating the classpath so that the class can be found).

In general, though, I look from my code toward the generated code until I find the error. If I get a NullPointerException, for example, I check to see if it's being caused by one of my classes. If it's a missing class, though, I won't find anything wrong with my own classes, so I'll start at the other end of the stack trace and look for a recognizable error.

Elie
+1  A: 

In your example, it looks like you need to add some Oracle JDBC driver or something to your project's classpath.

But in the spirit of the question, I think it depends. In this example Spring isn't being very helpful on it's own - error creating bean. Gee, thanks for that information. However, it tells you exactly WHY there was an error creating a bean. The "inner most" exception.

I've seen other examples where the inner most exception will be too specific (like an NPE) while on the outside the exception that was actually thrown had the most useful error message. It varies from project to project.

bpapa