Exception Caught Too Early

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.开发者_Python百科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.

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.

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.

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.