views:

985

answers:

4

I am getting an error in NetBeans saying I must throw an SQLException in this method:

private void displayCustomerInfo(java.awt.event.ActionEvent evt)                                     
{                                         
    int custID = Integer.parseInt(customerID.getText());
    String info = getCustomerInfo(custID);
    results.setText(info);
}

This method is created by NetBeans so it is not allowing me to edit the signature and throw the exception. This is why I created the getCustomerInfo() method. This method does throw the exception, because it uses a method to retrieve information from a database about a customer.

public String getCustomerInfo(int cid) throws SQLException
{
    Customer c = proc.getCustomer(cid);
    // get info
    return "info";
}

The getCustomer method also throws the exception and proc.java compiles.

The exact error is

unreported exception java.sql.SQLException; must be caught or declared to be thrown
+8  A: 

Read the error message again, it gives you two choices.

You must either declare the exception as thrown (which you cannot do) or catch the exception. Try the 2nd choice.

Darron
+2  A: 

It does not say you must throw it. It says you can catch it. So use a try/catch block and handle it.

try {
    ...
}
catch (SQLException e) {
    System.out.println("Exception happened! Abort! Abort!");
    e.printMessage(); //Not sure if this is the correct method name
}
Joe Philllips
+3  A: 

You need to put a try/catch block around your call to getCustomerInfo(), like so:

private void displayCustomerInfo(java.awt.event.ActionEvent evt)                                     
{                                         
    int custID = Integer.parseInt(customerID.getText());
    try {
        String info = getCustomerInfo(custID);
    } catch (SQLException sqle) {
        // Do something with the exception
    }

    results.setText(info);
}

A couple good options for handling the exception might be: logging the exception and the details used to get it, or using it as a signal to retry the connection request. Alternatively, as Outlaw Programmer shows, you could re-throw the Exception as a RuntimeException of some kind, which removes the requirement of checking.

Chamelaeon
+8  A: 

In general, if your code needs to throw a type of Exception that the signature doesn't support, and you have no control over the interface, you can catch and rethrow as a type the interface does support. If your interface doesn't declare ANY checked exceptions, you can always throw a RuntimeException:

private void displayCustomerInfo(java.awt.event.ActionEven evt)                                     
{        
    try
    {                                 
        int custID = Integer.parseInt(customerID.getText());
        String info = getCustomerInfo(custID);
        results.setText(info);  
    }
    catch (SQLException ex)
    {
        throw new RuntimeException(ex);  // maybe create a new exception type?
    }
}

You almost definitely want to create a new Exception type that extends RuntimeException, and have your client code catch that exception. Otherwise, you run the risk of catching ANY RuntimeException, including NullPointerException, ArrayIndexOutOfBoundsException, etc., which your client code probably can't handle.

Outlaw Programmer
I'll give you a +1 for having a correct answer that solves the problem, and may well end up being what the OP has to do, but could you please make mention that hiding things in RuntimeExceptions is generally considered bad practice? :D
rmeador
Its considered a bad practice by some. There are lots of cases where taking a checked exception (which should never have been in the java language according to some) and wrapping it in an unchecked exception is a good thing. Hibernate does this in all cases, eg.
jsight
I've edited the answer to explain the issue more clearly. I don't have a problem with RuntimeExceptions but I think it's probably worth it to make a new type so the client can at least know why the call failed.
Outlaw Programmer
In this case handling it is almost certainly better: write an error message using setText().
DJClayworth