# To prevent repository packages from triggering the installation of snap,
# this file forbids snapd from being installed by APT.
Package: snapd
Pin: release a=*
Pin-Priority: -10
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.
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.
VSCode con las extensiones de Remote Development instaladas.
Desarrollo en contenedores Docker.
Imagen Docker con chrome instalado.
Chrome no instalado en la máquina host.
Queremos utilizar el chrome del contenedor Docker para depurar nuestras aplicaciones.
Guía paso a paso:
Utilizar un Dockerfile basado en una imagen con chrome instalado (en mi caso, utilizo una imagen basada en Ubuntu 18.04 y personalizada para mis necesidades de desarrollo)
FROM rubensa/ubuntu-tini-dev-chrome# Keep container running (for use in VSCode)
CMD [ «tail», «-f», «/dev/null» ]
En el fichero devcontainer.json añadir la extensión Debugger for Chrome y forzarla para se se ejecute en «workspace» (en vez de en «ui«)
NOTA: para que esto funciona, también es necesario instalar la extensión localmente (pero manteniéndola deshabilitada Locally y habilitada en Dev Container)
Configurar los siguientes argumentos Docker dentro del fichero devcontainer.json
{
...
"runArgs": [
// X11 Unix-domain socket
"--mount",
"type=bind,source=/tmp/.X11-unix,target=/tmp/.X11-unix",
"--env=DISPLAY=unix${localEnv:DISPLAY}",
// Allow shared memory to avoid RAM access failures and rendering glitches due to X extesnion MIT-SHM
"--ipc=host",
// The kernel requires SYS_ADMIN for Chrome sand-box
"--cap-add",
"SYS_ADMIN",
// $(id -u):$(id -g)
"-u",
"1000:1000"
],
...
}
En mi Dockerfile particular debo especificar en devcontainer.json que VSCode no sobreescriba el comando por defecto de mi imagen.
{
...
"overrideCommand": false
...
}
Ahora, al abrir tu proyecto en Remote – Containers, podrás depurar el código dentro del contenedor.
Docker, para los contenedores que no definen su propia red – donde docker usa su dns interno que «delega» en el del host -, rellena el fichero /etc/resolv.conf de los contenedores copiando el /etc/resolv.conf del host y filtrando cualquier servidor de nombres local como podría ser 127.0.0.53. Si no hay ningún otro servidor de nombres, Docker añadirá los servidores DNS públicos de Google (8.8.8.8 y 8.8.4.4)
En Ubuntu 18.04, y otros sistemas que usan systemd-resolved, /etc/resolv.conf es un enlace a /run/systemd/resolve/stub-resolv.conf y su contenido siempre tiene la ip local 127.0.0.53:
nameserver 127.0.0.53
options edns0
y, como hemos explicado antes, Docker filtra cualquier dirección de loopback al leer el resolv.conf. Por tanto, nuestros contenedores Docker no usaran los DNS que utiliza el host, sino que siempre usará los DNS de Google.
Para solucionar esto, vamos a «tomar control» del fichero /etc/resolv.conf y a realizar las configuraciones necesarias para que los contenedores acaben usando la configuración de DNS del host.
La idea es sencilla.
En /etc/resolv.conf seguiremos referenciando como primer dns el 127.0.0.53 (que sabemos que Docker eliminará)
Además añadimos una nueva entrada referenciando al propio host (para que los contenedores Docker usen el host como servidor DNS)
El Blog de rubensa 