SQLException is the (noted) exception that JDBC apis are allowed to throw, so c3p0 should "wrap" the underlying Exceptions that did not eat SQLExceptions in the usual way. Calling getCause () for these Exceptions will provide the original Throwable if you want to check for something specific.
In the specific example that you are quoting, something else happens. The problem is that the Thread that throws the Exception is not your client thread. c3p0-internal threads acquire connections from the database. Your client threads acquire connections from the pool. These two actions are disengaged, since c3p0 can control - that's all that is connected with the Connection pool. First, internal threads perform a “round” of acquisition attempts (by default, 30 attempts with a delay of 1 second between them, but you can reconfigure if you want).
If ALL attempts to bypass the connection fail, the internal threads c3p0 ...
1) Record the failure and the last exception seen when trying. This is the second exception you are quoting. Please note that this is registered in WARNING and not at the DEBUG level. If you have c3p0 registered in INFO - what you need - you will see these messages. [If you want to see each individual Exception, all 30 Exceptions that must occur (under hyphens) before declaring a waiver, you need to enable registration in DEBUG (or FINE or ALL).]
2) After the log failed, c3p0 will abort wait () clients and throw a ResourcePoolException, which becomes a SQLException. This is the first exception you are quoting. A ResourcePoolException error is reported.
3) if breakAfterAcquireFailure is set to false (the default), the pool will recover after the acquisition fails. He will try to acquire new connections again when new clients appear. If breakAfterAcquireFailure is true, the pool will always respond to new client requests using Exception.
In any case, I hope this is not entirely useless. c3p0 can detect a custom exception type that will cause a wrapped exception to be delivered to clients, so clients can check for a failure in the code, but at least for now this is not the case. (Unfortunately!)