views:

70

answers:

3

Background: Hibernate connects to a database using a username and password entered into a GUI. Upon failure, instead of propagating the error up as an exception, it comes out as a stack trace in the logger. I don't know where the exception is being caught at. Also a tiny bit troubling is the following block:

if (reason != null)    {
    println("getConnection failed: " + reason);
    throw reason;
}

My breakpoint is set at the throw line (and successfully triggers), but the println statement never generates output (MySQL is using some sort of logger setup I can't find an open file hand for). Any sort of trick for locating where an exception is caught?

EDIT 1:

I call

sessionFactory = /*AnnotationConfiguration*/ ac.buildSessionFactory();

The exception is caught by Hibernate somewhere between the java.sql.DriverManager class and my HibernateUtil class. I presume we can blame Hibernate deciding that I don't really want to see the exception. I want to convince hibernate to let me see the exception.

EDIT 2:

My stack is this:

java.sql.SQLException: Access denied for user 'user'@'machine' (using password: YES)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:910)
    at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:3923)
    at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1273)
    at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2031)
    at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:718)
    at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
    at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:302)
    at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:282)
/* Exception is thrown on the next line (1st code block in original post). */
    at java.sql.DriverManager.getConnection(DriverManager.java:582)
    at java.sql.DriverManager.getConnection(DriverManager.java:154)
/* Begin hidden source calls */
    at org.hibernate.connection.DriverManagerConnectionProvider.getConnection(DriverManagerConnectionProvider.java:110)
    at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:84)
    at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
    at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
    at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:859)
/* End hidden source calls */
    at com.****.****.util.HibernateUtil.initialize(HibernateUtil.java:34)

I can't get the debugger to look at any point above the stack beyond DriverManager.java:582. Everything in the stack beyond that is not visible in the debugger.

A: 

Set a breakpoint for the exception thrown, and when the debugger starts single step to see what happens. You Will probably only need a few steps before the print happens.

Thorbjørn Ravn Andersen
Negative. I've already set the debug point and stepped down. Since I don't have the Hibernate source, after the exception throws I get tossed 5 calls back up the stack and never find out the information I need. I may get it to answer my question, but I really want to solve this without looking at the external library's source, and certainly without modifying the library.
Autocracy
Eclipse Can step through code without source. Which debugger dó you use?
Thorbjørn Ravn Andersen
+1  A: 

First of all, as you mention that there is a logger, you should replace all println statements with log calls.

You can also add further log messages to identify what happens inside the app. Alternatively (or in combination with the above), you can step through the critical code part in the debugger to see where the exception actually happens.

Péter Török
Usually yes, but it's not my source code that is using println. The one I mention in my question is from java.sql.DriverManager -- part of the JDK. I think I should stay outside of that. I know where the exception happens, I don't know where on the trace back up the stack its caught. This is all happening in the external Hibernate library. While I can get the source code for it, I'm leaning toward thinking I've asked the wrong question.
Autocracy
+1  A: 

Here's the end result: Line 116 of org.hibernate.cfg.SettingsFactory catches the sql exception and forces it to a log. No configuration is available to change this. It appears I'll be unable to tell my end-user why their connection fails unless I make use of the logs.

Netbeans, for some annoying reason after I gave it the source for Hibernate still wanted to call all of this "hidden source calls." Some time with VIM and reading the line numbers later, I've got it cleared up.

Autocracy