1
\$\begingroup\$

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;
}
\$\endgroup\$
  • \$\begingroup\$ Are these errors anything that the calling code would actually want/need to handle? \$\endgroup\$ – Winston Ewert Apr 1 '13 at 17:48
  • \$\begingroup\$ @WinstonEwert: No, the caller would only act on the fact that the role bean could not be created. It would not care or be able to make any decision on how to proceed based on the three individual exception types. \$\endgroup\$ – John Fitzpatrick Apr 1 '13 at 17:51
  • \$\begingroup\$ Under what circumstances would this bean fail to be created? \$\endgroup\$ – Winston Ewert Apr 1 '13 at 17:55
  • \$\begingroup\$ Programming errors would be the only cause I can think of. For example mis-spelling a property name in the array, or changing the setters/getters without adjusting the array. \$\endgroup\$ – John Fitzpatrick Apr 1 '13 at 18:03
5
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ I would like to just add that it would also be good to think about who needs to depend on what? Don't make other people depend on a API call that you made, instead as much as possible handle those yourself and if needed throw an exception that everyone has access too so you don't add to dependency. It would be annoying if you added another exception type and I had to change my code because you added something small. basically make me depend on you and not someone else as well as you. \$\endgroup\$ – Robert Snyder Apr 1 '13 at 19:15
1
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.)

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.