java - example - responsebuilder

WebApplicationException vs Response

Question

Entre todas las posibilidades de devolver una respuesta al cliente en un servicio REST , he visto dos posibilidades que parecen equivalentes: lanzar una WebApplicationException (posiblemente utilizando una instancia de Response ) o devolver una instancia de Response .

¿Por qué usar una posibilidad sobre la otra ya que el resultado es el mismo? ¿Está esto relacionado con el marco REST utilizado que puede configurarse para reaccionar de manera diferente entre las excepciones y las respuestas regulares?

Answer 1

¿Por qué usar una posibilidad sobre la otra ya que el resultado es el mismo?

¿Tal vez porque como programador (Java) está acostumbrado a lanzar excepciones cuando se rompen ciertas reglas de la aplicación? Convierta alguna cadena en un número y puede obtener una NumberFormatException , use un índice incorrecto en una matriz y obtiene una ArrayIndexOutOfBoundsException , ArrayIndexOutOfBoundsException algo a lo que no tiene permiso y obtenga una SecurityException etc. Está acostumbrado a lanzar excepciones cuando la "respuesta regular "no se puede crear (ya sea a partir de una entrada incorrecta o algún error de procesamiento).

Cuando no puede devolver la respuesta regular, debe devolver una respuesta de error al cliente. Puedes hacerlo lanzando la excepción o construyendo la respuesta a mano. Es lo mismo para su cliente, pero no es lo mismo para el código del lado de su servidor.

Lanzar la excepción hace que su código sea más limpio, más fácil de razonar y, por lo tanto, más fácil de entender . La idea es crear una subclase de la excepción WebApplicationException y crear sus propias excepciones significativas (p. Ej., ProductNotFoundException extends WebApplicationException { ... } excepción ProductNotFoundException extends WebApplicationException { ... } , AccessDeniedException extends WebApplicationException { ... } o reutilizando excepciones con un mapeador de excepciones ).

Entonces es más limpio throw new ProductNotFoundException() o throw new AccessDeniedException() y dejar que el marco lo maneje en lugar de crear una Response cada vez y luego seguir los detalles utilizados para construirlo para descubrir qué está sucediendo en esa sección de código.