When to catch/wrap an exception vs declaring that method throws exception

Question

In the snippet below the three exceptions I declare in the throws clause are all thrown by BeanUtils.setProperty(), which is a third party library.

Is letting these three exceptions "bubble upwards" with a throws declaration bad style? Is it better to wrap them in my own RoleBeanException and throw that?

public BeanRole getRoleBean(Request request) 
    throws IllegalAccessException, InvocationTargetException, NoSuchMethodException 
{
    String[] arrayOfProperties = {"application", "environment", "role"};
    BeanRole roleBean = new BeanRole();
    for (String strProperty : arrayOfProperties) {
        String strValue = BeanUtils.getProperty(request, strProperty);
        BeanUtils.setProperty(roleBean, strProperty, strValue);
    }
    return roleBean;
}

Answer 1

Programming errors should, as much as possible, produce unchecked rather than checked exceptions. Checked exceptions are for circumstances that will occur during the normal operation of the program and thus should be handled. For example, you should handle the IOException raised by attempting to open a file that isn't there. However, there is no reason to handle the exception raised by a misspelled property name. Programming errors in general should produce unchecked exceptions.

In this case, you should catch all those exceptions inside this function and rethrow them wrapped in a RuntimeException. Don't declare any exceptions types, those are only for exceptions that your caller should handle.

Answer 2

As a general rule of thumb, you catch an exception when you intend to do something with it , or when it matters to you . On the other hand , make the method declare that it throws the exception when you really don't care to bother with what happens when the exception occurs.

Answer 3

How you handle exceptions depends on how you want your code's interface to look. It basically comes down to how leaky you want your abstraction to be.

Propagate an exception if the caller could reasonably make sense of the exception.

Catch and throw your own exception (possibly wrapping the original exception) in all other cases.

For example, if you want the code that calls your method to be aware that your method uses reflection, then it may be OK to propagate an InvocationTargetException. If, however, reflection just happens to be the way your method is implemented, you wouldn't want to leak details of your method's inner workings by declaring those exceptions in your method signature. Instead, you should create your own type of exception that makes sense for the interface you are trying to define. (As @WinstonEwert advises, the exception class you create should be a subclass of RuntimeException if the problem is mostly the programmer's fault, and a checked exception if it's probably the user's fault.)