Guía completa a la gestión de excepciones en Spring Boot

La gestión de excepciones es una parte importante de la construcción de una aplicación robusta. Spring Boot ofrece más de un mecanismo de hacerlo.

Este artículo explora estos mecanismos y proporciona indicaciones de cuándo sería mejor un mecanismo u otro.

Introducción

Spring Boot nos proporciona herramientas para gestionar excepciones más allá de simples bloques «try-catch». Para usar estas herramientas, usamos varias anotaciones que nos permiten manejar la gestión de excepciones como un elemento transversal:

• @ResponseStatus
• @ExceptionHandler
• @ControllerAdvise

Antes de adentrarnos en estas anotaciones revisaremos cómo gestiona Spring las excepciones lanzadas por nuestros controladores web – nuestra última línea defensiva para capturar una excepción.

También revisaremos algunas configuraciones proporcionadas por Spring Boot para modificar el comportamiento por defecto.

Gestión de excepciones en Spring MVC

Spring MVC proporciona varias formas de gestionar el manejo de excepciones. Vamos a repasar dichas opciones teniendo en cuenta que nuestro objetivo es no gestionar las excepciones de forma explícita en mos métodos de los controladores siempre que sea posible.

Existen tres opciones: por excepción, por controlador o globalmente.

Spring Boot

Spring Boot permite tener un proyecto Spring con una configuración mínima y seguramente será lo que utilices en tu aplicación si ésta no tiene unos cuantos años.

Spring MVC no ofrece por defecto una página de error (fall-back). El modo más común de establecer dicha página de error por defecto siempre ha sido el SimpleMappingExceptionResolver.

Sin embargo, Spring Boot, sí que proporciona una página.

Al arrancar la aplicación, Spring Boot intenta encontrar un mapeo para /error. Por convenio, una URL que termina en /error se mapea con una vista lógica del mismo nombre: error. El mapeo real dependerá del ViewResolver (si hay alguno) que haya en la configuración de Spring Boot.

Si no se encuentra ningún mapeo para /error, Spring Boot define el suyo propio, la llamada «Whitelabel Error Page» (una página mínima con información del estado HTTP y detalles del error, tales como el mensaje de la excepción no capturada).

Si estás realizando una petición RESTful (la petición HTTP especifica una respuesta de otro tipo distingo a HTML), Spring Boot devuelve una representación JSON de la misma información que pone en la «Whitelabel Error Page».

Spring Boot también establece una página de error por defecto para el contenedor, equivalente a la directiva <error-page> de web.xml (aunque implementada de forma muy diferente). Así, las excepciones lanzadas fuera del framework Spring MVC, tales como las de los filtros de servlet, también son reportadas por la página de error de Spring Boot.

Eclipse MicroProfile

Historia

• 2016
  El 27 de Junio de 2016, durante una key note de la DevNation, Red Hat, IBM, Payara, Tomitribe y London Java Community anunciaron un Micro Profile para Java EE con el objetivo de optimizar las arquitecturas Java EE para microservicios.
  Se trataría de un nuevo Profile (introducidos en Java EE 6) no oficial.
  El 19 de Septiembre, durante la JavaOne 2016, se anunció la primera versión oficial.
  El 14 de Diciembre se anuncia que oficialmente MicroProfile se convierte en Eclipse MicroProfile.
• 2017
  El 8 de Agosto de 2017 se anunció en el hangout público de Eclipse MicroProfile la nueva versión MicroProfile 1.1, una nueva revisión que únicamente añadía una nueva especificación, la Config API. Esta especificación proporciona la capacidad de configurar la aplicación para diferentes estados/entornos del ciclo de vida de desarrollo software (Software Development Lifecycle SDLC) sin tener que re-empaquetar y re-construir la aplicación.
  El 3 de Septiembre de 2017 se anuncia la disponibilidad de MicroProfile 1.2, que actualiza el Config API y añade Health Check, Fault Tolerance, Metrics y JWT Authentication API.
  En Noviembre de 2017, Oracle se suma como miembro de la organización que soporta la iniciativa Eclipse MicroProfile.
• 2018
  El 3 de Enero de 2018 se anuncia la disponibilidad de Eclipse MicroProfile 1.3 que actualiza alguna versión de las APIs existentes y añade las de OpenAPI (para la generación automática de API para los microservicios), OpenTracing (que permite trazar las peticiones en una arquitectura de servicios distribuidos) y Rest Client (un modo consistente de invocar a los servicios).
  El 28 de Junio se anuncia la disponibilidad de Eclipse MicroProfile 1.4 y 2.0. La versión 1.4 se anuncia como la última compatible a nivel de versiones con Java EE7 mientras que la 2.0 se alinea con las versiones de la especificación Java EE 8 y añade el API JSON-B.
  El 19 de Octubre se anuncia MicroProfile 2.1 que trae como única novedad la revisión 1.2 del API Open Tracing.

Principales características de las versiones de JavaEE

Versión	Fecha de Lanzamiento
JPE	Anuncio en Mayo de 1998
J2EE 1.2	12 Diciembre 1999
J2EE 1.3	24 Septiembre 2001
J2EE 1.4	11 Noviembre 2003
Java EE 5	11 Mayo 2006
Java EE 6	10 Diciembre 2009
Java EE 7	28 Mayo 2013
Java EE 8	31 Agosto 2017

Principales características de las versiones de Java

Versión	Fecha de lanzamiento	Fin de Actualizaciones Públicas Gratuitas	Fin de Soporte Extendido
JDK Beta	1995
JDK 1.0	Enero 1996
JDK 1.1	Febrero 1997
J2SE 1.2	Diciembre 1998
J2SE 1.3	Mayo 2000
J2SE 1.4	Febrero 2002	Octubre 2008	Febrero 2013
J2SE 5.0	Septiembre 2004	Noviembre 2009	Abril 2015
Java SE 6	Diciembre 2006	Abril 2013	Diciembre 2018
Java SE 7	Julio 2011	Abril 2015	Julio 2022
Java SE 8 (LTS)	Marzo 2014	Enero 2019 para Oracle (comercial) Diciembre 2020 para Oracle (no-comercial) Al menos hasta Septiembre 2023 para AdoptOpenJDK	Marzo 2025
Java SE 9	Septiembre 2017	Marzo 2018
Java SE 10 (18.3)	Marzo 2018	Septiembre 2018
Java SE 11 (18.9 LTS)	Septiembre 2018	Al menos hasta Septiembre de 2022 para AdoptOpenJDK
Java SE 12 (19.3)	Marzo 2019	Septiembre 2019 para OpenJDK

De Java Web Start a…

Introducción

Con la llegada de Java 11, Oracle ha decidido eliminar todas las partes viejas y marcadas como obsoletas (deprecated) de la JRE. Desde el punto de vista de las aplicaciones de escritorio estas son las partes relevantes que se eliminan:

• Java Applets
• Java Web Start
• JavaFX

De JavaFX a OpenJFX

Introducción

JavaFX es la tercera generación de la plataforma de interfaz de usuario (GUI) de Java (tras AWT y Swing) para el desarrollo de Escritorio (Desktop) y de Aplicaciones de Internet Ricas (Rich Internet Application). Desde la JDK8 formar parte de Java SE pero, a partir de la versión 11, el proyecto será un módulo independiente.

De Java EE a Jakarta EE

Terminología

• Java EE
  Java EE, o Java Platform, Enterprise Edition, es el nombre de la versión empresarial de la plataforma Java que se construye sobre la Java SE o Java Platform, Standard Edition, añadiendo librerías que proporcionan funcionalidad que permite desplegar aplicaciones Java multicapa, distribuidas y tolerantes a fallos, basadas principalmente en componentes modulares ejecutándose en un servidor de aplicaciones. La evolución de esta plataforma está controlada por el Java Community Process (JCP). Su última versión es la Java EE 8, lanzada en Septiembre de 2017.
• Jakarta EE
  Jakarta EE es el nombre de la plataforma gobernada por el Jakarta EE Working Group (anteriormente EE.next Working Group). La primera versión es la Jakarta EE 8 que está basada en la versión de la Java EE 8 transferida de Oracle a la Eclipse Foundation.
• EE4J
  Eclipse Enterprise for Java (EE4J) es el proyecto de nivel superior dentro de la Eclipse Foundation que alberga todos los proyectos que permitirán crear todos los estándares a partir de la base de Jakarta EE. El EE4J Project Management Committee (PMC) es el responsable de mantener la visión general del proyecto de nivel superior.

La JVM

Partes de la JVM

Cadencia de versiones Java

De «major» a «feature»

A partir de Java 9, el ciclo de cadencia pasa de «major releases» (de unos 3 años) a «feature releases» (unos 6 meses).  En el pasado ya existían «feature releases», pero dentro de una misma versión.  Por ejemplo Java 8 se lanzó en Marzo del 2014.  8u20, una «feature release» se lanzó casi seis meses después, en Agosto.  8u40, la siguiente «feature release» se lanzó casi 6 meses después de esta.