How do I approach debugging by starting from writing the Java exception log?

I am trying to parse Java exceptions that appear in the log for some code that I am working with. My question is, are you parsing the exception trail from top to bottom or bottom to top? 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 an answer to this particular exception, but how are you going to parse the exception trace like this? Are you starting with the top-level error, or are you starting with the innermost error (in the "caused" section)?

The problem is harder for me because I am not working with the code I wrote. I am editing XML config so I don't even look at Java code. In my own code, I would recognize the locations in the trail and know what to look for. So how do you feel about generic exclusion in general?

0


source to share


3 answers


Your specific example is missing a class. Once you see an error like this, you know what to fix (either fix the class name or update the classpath so that the class can be found).



In general, however, I look from my code at the generated code until I find an error. For example, if I get a NullPointerException, I check to see if it was called by one of my classes. However, if this is a missing class, 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.

+1


source


This stuff is a little difficult to explain, but my first step almost always starts at the top and drops down until I see a familiar one com.mycompany.myproject

.

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



Edit: But, rereading your question, you say that this is not your code .. so it might not be a very useful answer.

+2


source


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

But in the spirit of the question, I think it depends. In this example, Spring is not very useful on its own - throwing a bean error. Thank you for this information. However, it tells you exactly why the error occurred while creating the bean. The "innermost" exception.

I've seen other examples where internally most of the exceptions would be too specific (e.g. NPE), and externally the exception that was actually thrown had the most helpful error message. It varies from project to project.

+1


source







All Articles