Creo que un factor importante es quiénes son sus clientes de servicio.
Si su capa de servicio es solo un límite arquitectónico entre capas en su propio proyecto, y el cliente de servicio está dentro del mismo ámbito de confianza, entonces está bien relajar las cosas y dejar que las excepciones no verificadas broten a la capa de controlador o al cliente de servicio.
Sin embargo, para el código público; servicio que es consumido por un tercero o cliente, creo que es más limpio envolver cualquier excepción no verificada con una excepción orientada al servicio, principalmente por cuestiones de seguridad, en segundo lugar por acoplamiento flojo y abstracción limpia.
Una excepción de la capa de datos nunca debe llegar directamente a un usuario final de una aplicación web . Potencialmente contiene información interna sobre su esquema, sus consultas, información de número de línea, nombres de variables o funciones, etc. Las excepciones del usuario final se pueden desinfectar en una configuración segura.
Un cliente de servicio externo no está preocupado con los detalles de su implementación, y de todos modos no puede manejar excepciones no verificadas, ya que son errores o problemas ambientales. En aplicaciones seguras, los errores de la base de datos simplemente no son lo suficientemente seguros como para propagarse, OracleException - ORA-01234 - ...
que podría ser la tercera tabla que se insertó. Se debe permitir que el cliente se ocupe de cualquier excepción comprobada / esperada que pueda manejar, y trate todo lo demás como un posible informe de error. Su contrato de servicio debe ser una abstracción atómica, consistente y transaccional. Si no puede hacer nada con respecto a la excepción, entonces lo único útil que queda es darle un informe de error. Ya tiene la capacidad de registrar la excepción, entonces, ¿por qué cargar a su usuario final con los detalles? Su aplicación puede monitorearse para que ya sepa sobre las excepciones no verificadas antes de que los usuarios las denuncien.
Nunca está bien comer excepciones, ni soy fanático de las excepciones marcadas, pero prefiero tener un plan que sea apropiado para la naturaleza del producto en general.
La razón principal por la que se usaría el ajuste de excepción es para evitar que el código en la capa empresarial tenga que conocer cada posible excepción en el sistema . Existen dos motivos principales para esto:
Consistencia: las excepciones declaradas se agregan hacia la parte superior de la pila de llamadas. Si no ajusta las excepciones, sino que las pasa declarando sus métodos para lanzarlas, puede terminar con métodos de nivel superior que declaran muchas excepciones diferentes. Declarar que todas estas excepciones en cada método respaldan la pila de llamadas se vuelve tedioso.
Encapsulación: es posible que no desee que sus componentes de nivel superior sepan nada sobre los componentes de nivel inferior, ni las excepciones que arrojan. Por ejemplo, el propósito de las interfaces e implementaciones DAO es abstraer los detalles del acceso a los datos lejos del resto de la aplicación. Ahora, si sus métodos DAO arrojan SQLException, entonces el código que usa los DAO tendrá que atraparlos. ¿Qué sucede si cambia a una implementación que lee los datos de un servicio web en lugar de una base de datos? Entonces sus métodos DAO tendrán que lanzar tanto RemoteException como SQLException. Y, si tiene un DAO que lee datos de un archivo, también necesitará lanzar IOException. Esas son tres excepciones diferentes, cada una vinculada a su propia implementación DAO.
Entonces, en resumen, ¡la respuesta es sí!
fuente