31

Among all the possibilities to return a response to the client in a REST service, I've seen two possibilities that look equivalent: throwing a WebApplicationException (possibly using a Response instance) or returning a Response instance.

Why to use one possibility over the other since the result is the same? Is this related to the REST framework used that may be configured to react differently between exceptions and regular responses?

manash
  • 6,985
  • 12
  • 65
  • 125
  • 1
    I see `WebApplicationException` as being for failure cases rather than success cases. If you have a method that would normally return (say) a JAXB object in the success case, throwing a `WebApplicationException` provides a way to return some other kind of data in the failure case. But if the method is declared to return `Response` in the success case then there's less need for the exception approach. – Ian Roberts Nov 13 '12 at 11:00
  • 1
    Take a look at the [Jersey documentation](http://jersey.java.net/nonav/documentation/latest/jax-rs.html#d4e435) for some ideas of `Response` vs. `WebApplicationException`. For success, always use `Response`. –  Nov 13 '12 at 14:40
  • @IanRoberts I understand the fact one is generally used for failures and the other for success scenarios. But my question is more technical i.e. is there a difference about how the response is interpreted or processed by the framework if it's an exception or a regular response? (I've added the Jersey tag). – manash Nov 13 '12 at 20:10
  • @LutzHorn For success I don't use exceptions since this is counter intuitive although it works. But for failures, there is a choice. – manash Nov 13 '12 at 20:11

1 Answers1

30

Why to use one possibility over the other since the result is the same?

Maybe because as a (Java) programmer you are accustomed with throwing exceptions when particular rules of the application are broken? Convert some string to a number and you might get a NumberFormatException, use a wrong index in an array and you get an ArrayIndexOutOfBoundsException, acces something you are not allowed to and get a SecurityException etc. You are used to throwing exceptions when the "regular response" can't be created (be it from wrong input or some processing error).

When you can't return the regular response, you must return an error response to the client. You can do that with either throwing the exception or building the response by hand. It's the same thing for your client, but it's not the same thing for your server side code.

Throwing the exception makes your code cleaner, easier to reason about and thus easier to understand. The idea is to subclass the WebApplicationException and create your own meaningful exceptions out of it (e.g ProductNotFoundException extends WebApplicationException { ... }, AccessDeniedException extends WebApplicationException { ... } or reusing exceptions with an exception mapper).

It's then cleaner to throw new ProductNotFoundException() or throw new AccessDeniedException() and let the framework handle it instead of building a Response every time and later follow the details used to build it to figure out what's happening in that section of code.

Bogdan
  • 23,890
  • 3
  • 69
  • 61
  • 9
    There is another reason to throw an exception: If you are using transactions, it allows the container to rollback any changes that you had previously made to your data within that request. If you just return a regular response, you will need to take care of that by your self. – st-h Jun 19 '13 at 12:54
  • what do you mean "let the framework handle it"? Do you have any article I can refer to for how this works? Thanks. – Cacheing Jan 02 '14 at 18:22
  • @Cacheing: [The JAX-RS specs](http://download.oracle.com/otndocs/jcp/jaxrs-1.1-mrel-eval-oth-JSpec/) mention how the WebApplicationException should be handled. You can even register an Exception Mapping Provider, also described in the specs. – Bogdan Jan 02 '14 at 20:45
  • exception would be preferred to trigger alerts on exception rates – vaibhav.g Aug 03 '21 at 06:49