Using Checked Exceptions vs Unchecked Exceptions with REST APIs

Question

According to [1],

"When deciding on checked exceptions vs. unchecked exceptions, ask yourself, What action can the client code take when the exception occurs?. If the Client code cannot do anything, Make it an unchecked exception. And if the Client code will take some useful recovery action based on information in the exception, make it a checked exception."

I get the overall idea. However, my confusion is, what it meant by the "Client code". Let's say I'm writing a REST API, which has a Service Layer that calls the Actual Backend Layer (where I do the validation as well).

API User --calls--> { |Service Layer| --internally calls--> |Backend Layer| }

1. So the API User is also considered as a "Client code"?
2. For request validations, should I throw Checked or Unchecked Exceptions?
3. Is the best practice to avoid using checked exceptions?
4. Is is ok to throw unchecked exceptions in validations, and let it bubble up, and catch and wrap it with in a custom exception at the Service Layer? (and use JAX-RS ExceptionMapper [3] to show that to the API user)

References:

[1] http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html

[2] http://archive.oreilly.com/pub/post/avoiding_checked_exceptions.html

[3] https://docs.oracle.com/javaee/6/api/javax/ws/rs/ext/ExceptionMapper.html

Answer 1

Q1: So the API User is also considered as a "Client code"?

Yes.

Q2: For request validations, should I throw Checked or Unchecked Exceptions?

Quoting from the advice in your question: "If the Client code cannot do anything, Make it an unchecked exception. And if the Client code will take some useful recovery action based on information in the exception, make it a checked exception."

Q3: Is the best practice to avoid using checked exceptions?

No.

Q4: Is is ok to throw unchecked exceptions in validations, and let it bubble up, and catch and wrap it with in a custom exception at the Service Layer? (and use JAX-RS ExceptionMapper [3] to show that to the API user)

"Is it OK" depends on who you ask. It also depends on whether it works for you.

If you turn everything into unchecked exceptions, then the compiler cannot help you by checking that exceptions that ought to be handled are handled.

In your model, something must sort out the errors that need to be handled by the caller of the client API from those that don't. It can be done ... but you are much more dependent on the API client programmer to know what is the right things to do. Without checked exceptions, he / she is able to simply ignore the exceptions ... until they cause system test failures, failures in production.

How good are your programmers? How good is your documentation? How good is your quality control / testing regime?