I've literally never seen somebody catch a SQLException and do nothing with it - you quickly learn that just doesn't work, and it would never pass a code review

I've literally never seen somebody catch a SQLException and do nothing with it - you quickly learn that just doesn't work, and it would never pass a code review. With respect to exposing implementation details: If the caller is the one who passed in the connection, then it makes complete sense to throw a SQLException so the caller can deal with it. If the connection was opened in your method, then yes you probably should wrap it, handle it properly and clean up the connnection, and then throw a different exception. The only time it's ambiguous is if the connection came from an instance variable. That's often a poor design, but usually means it came indirectly from the caller and so it still makes sense to throw SQLException. In general, SQLException works fairly well as a checked exception. If some code generates a SQLException, your transaction failed and you should generally abort it (or you can check the specific error code if you are prepared to handle anticipated failures such as a duplicate key error). If it generates any other exception, you can continue working with the database (such as saving the failure status to a table).