InterruptedException is wrapped within an SQLException in C3P0PooledConnection

[robertverdes]

I saw it's thrown all the way from BasicResourcePool.prelimCheckoutResource to C3P0PooledConnectionPool.checkoutAndMarkConnectionInUse - but in checkoutPooledConnection, it's then masked by a catch-all Exception block.

Working with interrupting threads becomes hard to follow in this case. When it's interrupted while doing a getConnection(), it throws an SQLException caused by an InterruptedException. To handle this, you have to:

catch (SQLException e) {
    Throwable cause = e.getCause();
    if (cause instanceof InterruptedException) { .... }
}

which is a bit of a stretch, and not really politically correct.

Wouldn't it be nicer to just let us handle an InterruptedException directly?

[swaldman]

This can't be done. InterruptedException is a checked Exception, and DataSource.getConnection() does not throw it. The InterruptedException can't be passed through. It has to be caught and then converted.

Even if it were possible, I'm not sure I'd want to do what you are suggesting. c3p0 uses interrupts internally, to wake up client Threads when it decides a call to getConnection() can't be fulfilled. But its use of interrupts strikes me as an implementation detail I'd not particularly want to leak. If you yourself are interrupt()ing Threads, and trying to use the InterruptedException to draw inferences about the circumstances under which getConnection() failed, be aware that c3p0 also sometimes calls interrupt() on the Threads it holds wait()ing, so it is not safe to presume that your code was the source of the interrupt().