在 http API 中对“错误请求”引发异常是否是一种好习惯 - 与（Java）最佳实践相矛盾

Question

Normally I try to use exceptions only for "exceptional" conditions ("Effective Java ", Issue 69) . My personal interpretation is: if I hit a condition in a specific part in code (normally a method or constructor) where I can't give a meaningful answer or outcome anymore I throw an exception and whoever called the piece of code has to handle it.

In the special case of HTTP endpoints I can always give a meaningful answer - a response with a status code. Handling bad requests thus belongs to normal program flow of endpoint methods and should not raise new exception.

Eg an endpoint that returns a resource should just return 404 in case the resource is not found. In my opinion it would be bad practice to raise a "SomethingNotFoundExcetion" (that could be handled by an error handler and create 404 response)

My question is: It is bad practice to use Spring Boot's error handling mechanism for bad requests (4xy) that relies on exceptions to create specific HTTP responses. (It is really fine for all uncovered errors yielding 500)

(I am just writing a review of code and I am not sure if I should suggest to not use error handler for "normal" API interaction)

Answer/Comment to current answers

It seems that the most of you missed the important part of my reasoning: (citing Effective Java, Item 69):

Use exceptions only for exceptional conditions ...

this reasoning: • Because exceptions are designed for exceptional circumstances, there is little incentive for JVM implementors to make them as fast as explicit tests. • Placing code inside a try-catch block inhibits certain optimizations that JVM implementations might otherwise perform.

The main point for me is:

A well-designed API must not force its clients to use exceptions for ordinary control flow.

Especially in case of rest API. It should be easy to use any API in a way to avoid exceptions at all. This means for me. No correct (defined eg in Open API) usage of a Rest API should raise an exception.

To put another point: The standard for SOAP (another http based API stuff) forbids to use "SOAP fault" for correct (defined by WSDL) requests.

For me raising exception in remote APIs on not exceptional cases are even worse then in classic API (via dependency).

Answer 1

It depends on your project, it's really a matter of opinion/architectural decision. I'd say either-or.

The advantage of using specific Exception s and then using a Spring handler to map them is that it removes the tedious construction of responses with the correct code from the actual application logic code (it's not dissimilar from aspects in that respect): just throw the correct exception and be done with it.

OTOH, the distance to the error handling code means that 1. if something doesn't work, it may be difficult to track down the issue 2. you need to know what exceptions to throw, and that is not immediately obvious and needs to be documented well.

Answer 2

It is not a bad practice, but a matter of architectural decision. It could be good to have an error handler that will produce a 4xx response and will do some additional error handling work, such as logging, and/or sending a notification by mail or queue or (like in my project) write errors in the table so they could be reviewed by user using GUI component of an application and may be even edited and re-submitted if it makes sense. It also unifies the error handling to a single code (code re-use). But if you really just need to send a 4xx response and nothing else, then its OK not raise exception and just do it in your code. Raising exception is expensive performance-wise and shouldn't be done just for the sake of raising exception alone. But in this particular case my opinion is to use Exception/Spring boot Error handling mechanism