How do I avoid this SQL exception?

Question

I have a DBconnector class that I've written. Here is an instance of it using an insert query method it has. Ignore the query for now:

ResultSet NewCustomer = db.executeInsert("SELECT s Bookings VALUES (surnameOut,'Nilsen', 'Johan', 'Bakken 2', 'Stavanger')");

At the moment the above line is getting a "Unhandled exception type SQLException" error. It suggests that I surround the above with a try/catch statement, or give the method that hold's the code a throws exception. I was hoping there was some way to sort it out from within the DBconnector class, so that I can maintain tiny, single lines for executing SQL queries. Is this possible?

Here is the code from the method executeInsert method:

public ResultSet executeInsert(String query)throws SQLException {
        Statement s = null;
        ResultSet rs = null;
        try{
            s = con.createStatement();
            s.executeQuery(query);
            rs = s.getResultSet();
        }
        catch(SQLException e){}
        return rs;
    }

score 5 · Answer 1 · answered Mar 14 '12 at 23:24

I was hoping there was some way to sort it out from within the DBconnector class, so that I can maintain tiny, single lines for executing SQL queries.

So what do you want to happen when you've got a broken query (e.g. because you're trying to execute an insert which actually selects). Do you really want to just completely ignore the failure, without even logging it, as your current method does? That's almost never the right approach. In many cases, if a database query fails, you should abort whatever you're doing - the exception should bubble up the stack to some high level "unit of work" whether that's a request, a user action or whatever.

The reason for Java's checked exceptions is precisely to force you to think about how you want to handle errors - so don't ignore it, really think what you'd like to happen... and if this method doesn't have enough context to say (which it probably doesn't) you should let the exception bubble up, and force the callers to think.

So are you advocating the try/catch outside of it? And does this make the try catch within executeInsert redundant? — Chucky, Mar 14 '12 at 23:38
@Chucky: Usually I'd end up very few try/catch blocks - and I'd definitely *either* remove the one here, or use it *just* to wrap the checked exception in an unchecked one. — Jon Skeet, Mar 14 '12 at 23:49

score 2 · Answer 2 · edited May 23 '17 at 10:24

This is (essentially) the old checked exceptions argument - some people love them, some people hate them (see here).

I, for one, don't like checked exceptions (Is it dangerous to disagree with Mr. Skeet @ 415k reputation??!), so when I'm forced to deal with one, I generally use a try/catch and rethrow the error as a custom made subclass of RuntimeException. RuntimeExceptions don't need to be handled explicitly.

Spring, which is one of the most heavily used frameworks around, takes this approach.

When you use RuntimeExceptions, though, make sure that at some point you know where that exception is going to be handled. You never want it to go all the way to your end user and let them see a nasty stack trace.

I'm not a huge fan of checked exceptions either - I think they were an interesting experiment which didn't quite work, possibly because they've been overused. Basically I think we're a long way off "solving" the issue of reacting to errors :( — Jon Skeet, Mar 14 '12 at 23:50

score 0 · Answer 3 · answered Mar 15 '12 at 01:50

To answer your question, your method in DBConnector explicitly says it throws a SQLException (even if it isn't). Because SQLException is a checked exception, you need to deal with it with whatever code calls it.

It sounds like this is not the case you want though. If you remove the throws SQLException , you can write your tiny SQL code. Be sure to take the advice of the other answers though because you are effectively ignoring problems which may not be a good thing.

How do I avoid this SQL exception?

3 Answers3