¿Cómo decides entre una excepción checked y una unchecked, y cómo manejas las excepciones en un servicio?

Usa una excepción checked solo cuando quien llama pueda recuperarse de verdad y quieras que el compilador le obligue a decidir; usa unchecked para errores de programación y para fallos que nadie más arriba puede arreglar. En la práctica, la mayoría del Java moderno se inclina por unchecked, envolviendo fallos de bajo nivel en una excepción de dominio que lleva contexto, manejada una sola vez en una frontera, como un manejador de excepciones que la mapea a una respuesta.

Mi prueba es si quien llama puede hacer algo útil con ello. Un pago rechazado por el proveedor es un resultado de negocio legítimo, así que eso es una excepción checked o, más a menudo, un tipo resultado. Un argumento nulo o una conexión a base de datos fallida no es algo que el código llamante pueda arreglar, así que es unchecked. En servicios uso sobre todo excepciones de dominio unchecked, envolviendo la causa subyacente para que sobreviva la traza y añadiendo los identificadores que voy a querer en el log, como el id del pedido, porque una excepción SQL pelada tres capas más abajo no me dice nada. El manejo ocurre una vez, en una frontera: en Spring eso es un manejador de excepciones que mapea cada excepción de dominio a un código de estado y a un cuerpo de respuesta, así los controladores quedan limpios. Lo que rechazo en revisión es capturar Exception de forma amplia, capturar y loguear y seguir como si nada, y los bloques catch vacíos. También uso try with resources en todas partes en lugar de bloques finally, porque las excepciones suprimidas y los fallos al cerrar se manejan bien y gratis.