ATENCIÓN: este contenido tiene más de 2 años de antigüedad y, debido a su temática, podría contener información desactualizada o inexacta en la actualidad.
En la versión 9 de Node.js llegaron cambios a la forma de lanzar y gestionar errores en tiempo ejecución. Estos cambios empezaron a aparecer ya en versiones tardías de Node.js 8 y se continuaron y terminaron en las versiones 9.x.
Hasta su versión 8, la mayoría de los errores lanzados por Node.js consistían tan solo en un mensaje de texto asociado a los mismos. Si querías que tu código se comportarse de una forma determinada en función de cuál fuese el error, lo que tenías que hacer era comparar la cadena de texto del mensaje de error con algún valor conocido. El resultado era código de este estilo:
try {
//hacer una llamada a la API de Node.js aquí
} catch (error) {
if (error.message === 'Este es l mensaje' {
// haz algo
} else {
// haz otra cosa
}
}
Es evidente que esto es una fuente de problemas. Para empezar ese mensaje puede cambiar con el tiempo. Bastaría con que cambiase una coma para que ya no se detectase correctamente. Por otro lado si te equivocas y metes un error tipográfico (como de hecho hemos puesto en el fragmento anterior, a propósito), tampoco te funcionará.
Además para el equipo que está desarrollando Node.js también era un problema grave. Cuando aparecía un error y lo querían arreglar, aunque solo fuera un pequeño fallo tipográfico en un mensaje de error, debían marcar el cambio como un cambio "mayor" de SemVer (versionamiento semántico); ya que el cambio podía romper la compatibilidad hacia atrás de todos los desarrolladores que estuvieran usando la cadena en una comparación y así detectar el error. Esto implica que el cambio solo se puede incluir en el siguiente lanzamiento "mayor" (la siguiente versión grande que cambia el primer número) y que no se puede portar hacia atrás a las versiones anteriores. En el caso de un error tipográfico quizás no sea nada muy importante, pero si se tratase de un mensaje que está mal o que lleva a conclusiones erróneas puede que sea una preocupación más grave.
La fuerte dependencia en la cadena de texto del mensaje también supone un reto para la internacionalización. Node.js ha hecho grandes avances en este frente a través de la incorporación de ICU y APIs para poder internacionalizar código de aplicaciones. Para dar un paso más y permitir la internacionalización de los mensajes de error que devuelve Node.js, se debía permitir que el error en concreto pueda identificarse sin utilizar en absoluto la propia cadena del mensaje de error. Si no se hiciese así no se podrían internacionalizar los mensajes, ya que según el idioma de cada servidor podrían cambiar y no habría forma de detectarlos comparando las cadenas de texto.
Los cambios que se han llevado a cabo consisten en añadir un "código" a todos los objetos de error lanzados por las APIs de Node.js, los cuales se pueden consultar en la documentación de la API de Node.js.
Esto permite que el ejemplo de código anterior se pueda volver a escribir de esta manera:
try {
// hacer una llamada a la API de Node.js aquí
} catch (error) {
if (error.code === 'ERR_INVALID_URL_SCHEME' {
// haz algo
} else {
// haz otra cosa
}
}
Manera mucho más clara, eficiente y que, si el mensaje cambia en el futuro, el código no se vería afectado dado que el código del error no habrá cambiado. Además de poder detectarlo independientemente de los ajustes de localización en los que se ejecute la aplicación de Node.js.
Ahora que los códigos de error están incorporados a Node.js, es posible que actualicen los mensajes de error sin tener que esperar a nuevas versiones "grandes", y sin romper la compatibilidad de tu código..
¿Qué debes hacer?
Si usas el estilo antiguo de "parsear" las cadenas de mensajes de error para gestionar tus errores lo que debes hacer es:
- Localiza todos los fragmentos de código en los que estés utilizando la cadena del mensaje de error. Debería ser muy fácil con una simple búsqueda de tu editor de código favorito.
- Una vez hecho esto, salvo en los casos en los que no sea absolutamente necesario (y no debería serlo), elimina el código que haga uso de esas cadenas de texto de mensajes de error.
- Actualiza el código para emplear el código de error correspondiente en lugar del mensaje, usando la lista de errores enlazada anteriormente para localizar el más apropiado.
Si necesitases dar soporte simultáneo a más de una versión de Node.js (una antigua y una nueva), de modo que se soporten ambos estilos de gestión de errores, puedes hacer algo como esto:
try {
// hacer una llamada a la API de Node.js
} catch (error) {
if ((!error.code && (error.message === 'Este es l mensaje')) | |
(error.code === 'ERR_INVALID_URL_SCHEME')
) {
// haz algo
} else {
// haz otra cosa
}
De este modo podrás mantener el código antiguo si en tu servidor o el de un cliente no puedes actualizar la versión de Node.js, y tendrás el código preparado para funcionar sin cambios en cuanto actualices a una versión reciente del runtime de Node.js.
Fecha de publicación: