JavaScript soporta try/catch/finally pero el objeto de Error que usa funciona de manera diferente a las excepciones en otros lenguajes y no proporciona una forma de detectar errores por tipo de la misma manera que puede con excepciones en Java o C#, Por lo que es bastante común que todos los errores arrojados en un proyecto sean instancias de Error.
algunos Proveedores han implementado una cláusula de captura condicional, pero no es un estándar y no está ampliamente soportado en los navegadores.,
como resultado de no tener una forma estándar de definir errores, o de devolverlos cuando se lanzan desde un servidor a un cliente, la información sobre un error que se devuelve a menudo se pierde, con proyectos que ofrecen un manejo de errores a medida.
lanzar errores en otros idiomas
si alguna vez ha utilizado.Net / Mono, puede apreciar lo bueno que es el comportamiento de manejo de errores, especialmente para los servicios web.
si no está familiarizado con la pila. NET/Mono bare conmigo aquí por un minuto, volveremos a cómo es relevante a continuación.
convenciones de Nomenclatura
.,NET tiene convenciones de nomenclatura para errores, como InputValidationExceptionpara Errores de validación de entrada y SecurityException para Errores de permisos, lo cual es ideal para fomentar la coherencia en el manejo de errores.
errores de serialización
otra gran característica de.NET es que lanzar una excepción en el servidor en un servicio web automáticamente puede lanzar automáticamente esa excepción en un cliente que usa el servicio, ya sea que el cliente sea C#, Java, PHP o JavaScript.,
esto es posible gracias al lenguaje de descripción de Servicios Web (WSDL), que define cómo los objetos, incluidas las excepciones, se serializan y tiene soporte nativo en algunos lenguajes (incluidos C# y PHP) y soporte a través de bibliotecas de terceros en otros (incluidos Java y JavaScript).
beneficios de tener una convención
Lo bueno de tener convenciones para errores es que hace que sea más fácil manejar bien errores específicos porque tienen tipos explícitos y consistentes.,
con los tipos de error predefinidos, puede decidir fácilmente la cantidad de detalles que desea devolver al cliente (como los nombres de los campos que fallaron en la validación y lo que estaba mal con ellos) mientras registra información adicional de seguimiento de pila en el servidor cuando se activan errores inesperados.
También puede agregar propiedades específicas a un error, para que sea más fácil resaltar DÓNDE ESTÁ un problema, como un campo de entrada con un valor no válido.
La serialización es automática y consistente en toda una aplicación, incluso entre clientes y servidores., Esto hace que sea más fácil manejar los errores bien del lado del servidor y en una interfaz de usuario.
Definir tipos de error en JavaScript
JavaScript en realidad tiene varios tipos de Error principales por defecto, pero son bastante nicho y de utilidad limitada para el manejo de errores en la mayoría de las aplicaciones.
sin embargo, con ES6 puede ampliar la clase de Error y definir errores personalizados con su propio comportamiento, como errores de registro automáticamente, y puede elegir qué detalle agregar o incluir al devolver un error.,
Puede definir cada clase en un archivo o, si solo tiene un pequeño número de tipos de error, que es probablemente el caso de la mayoría de los proyectos, puede definirlos todos en un solo archivo como exportaciones con nombre.
un ejemplo de exportar diferentes tipos de Error como exportaciones con nombre:
Puede usar Errores personalizados en su código al igual que lo haría con un Error normal:
Nota: Este ejemplo es para Nodo.js y utiliza ‘require’., Si lo estuviera escribiendo para ES6 en el navegador (o usando Babel para código isomórfico) escribiría la instrucción include como import { ValidationError } from './error'
Cuando arroje un error personalizado, puede verificar qué tipo es (p. ej., al observar el valor de .name) y decidir cómo manejarlo en consecuencia:
definir una propiedad name, una propiedad estándar de la clase Error en JavaScript, proporciona una forma de verificar fácilmente el tipo de Error si está serializado en un objeto estándar en una llamada REST o en una devolución de llamada de servicio socket, para que pueda lanzar el Error por ejemplo, desde un método interno, al controlador de rutas del servidor web y todo el camino a un navegador, y aún así saber lo que sucedió.,
si devuelve un error de un servicio basado en REST o socket, el Error generalmente se serializará en JSON y back, y es probable que se transforme en un objeto plano (y ya no sea un objeto de Error) cuando el cliente evalúe la respuesta, pero definir tipos de error como este en sus proyectos puede ayudar a proporcionar una convención para devolver y verificar errores.
devolver objetos de Error de Promises
También puede usar objetos de Error personalizados dentro de una promesa.,
Es mejor evitar lanzar errores desde dentro de una promesa, porque no siempre pueden ser capturados, dependiendo de cómo esté estructurado el código que los llamó.
sin embargo, es una buena práctica devolver un error al rechazar una promesa, y puede devolver tipos de Error personalizados como cualquier otro Error.
al llamar a la función, sucatch() cláusula puede comprobar para ver la respuesta cuando se devuelve un error. Si devuelve una instancia de Error (o una clase que la extiende) tendrá un seguimiento completo de la pila del error que se lanzó.,
cualquier código que ya esté usando esta función y que estuviera esperando un objeto de Error será compatible con un Error personalizado que extiende la clase de Error predeterminada.
serialización de objetos de Error en JSON
de forma predeterminada, los objetos de Error se seralizan en JSON con una salida como esta:
{ name: 'ValidationError' }
Esta salida no es particularmente útil si desea pasar los errores directamente a una interfaz web desde un marco como Express o Socket.IO.,
Puede anular el método de serialización para devolver una respuesta diferente:
este ejemplo devuelve la respuesta encapsulada en una propiedad llamada ‘error’, lo que facilita la comprobación de las respuestas. Se seraliza a JSON de la siguiente manera:
{
error: {
name: 'ValidationError',
message: 'A validation error',
stacktrace: '…'
}
}
Si tiene varios tipos de error, es posible que desee crear su propia clase de error personalizada que extienda el Error y luego basar todas sus clases de error en eso.,
usar códigos de estado HTTP es apropiado en servicios HTTP, pero tener un formato estándar para errores en JSON sigue siendo útil, especialmente en otros contextos, como las respuestas enviadas a través de una conexión de socket.
es posible que no desee incluir un seguimiento de pila (con nombres de archivo y números de línea) en producción, pero puede ser útil en desarrollo y pruebas y puede usar un condicional para que solo se devuelvan en desarrollo.,
resumen
seguir el ejemplo de cómo funciona el manejo de errores en otros lenguajes como Java y C# y definir Errores personalizados con métodos estándar para seralizarlos requiere no requiere mucho código para implementar y proporciona una convención consistente y fácilmente comprensible a seguir.
establecer buenas convenciones de manejo de errores en un proyecto puede hacer que sea más fácil mejorar la experiencia del usuario de su software, aplastar misteriosos mensajes de «error desconocido», rastrear causas de comportamiento inesperado y hace que sea más fácil registrar, monitorear e informar sobre errores.
