Inicio>Relacionado con la programación>código fuente JAVA
Descargar

Manual de errores de JavaScript

Este README contiene información que he aprendido a lo largo de los años sobre cómo lidiar con errores de JavaScript, informarlos al servidor y navegar a través de muchos errores que pueden hacer que todo esto sea realmente difícil. Los navegadores han mejorado en esta área, pero aún queda margen de mejora para garantizar que todas las aplicaciones puedan manejar de manera sensata y sólida cualquier error que ocurra.

Los casos de prueba del contenido que se encuentra en esta guía se pueden encontrar en https://mknichel.github.io/javascript-errors/.

Tabla de contenido

  • Introducción

  • Anatomía de un error de JavaScript

    • Produciendo un error de JavaScript

    • Mensajes de error

    • Formato de seguimiento de pila

  • Detectar errores de JavaScript

    • ventana.onerror

    • probar/atrapar

    • Puntos de entrada protegidos

    • Promesas

    • Trabajadores web

    • Extensiones de Chrome

Introducción

Detectar, informar y corregir errores es una parte importante de cualquier aplicación para garantizar el estado y la estabilidad de la aplicación. Dado que el código JavaScript también se ejecuta en el cliente y en muchos entornos de navegador diferentes, estar al tanto de los errores JS de su aplicación también puede resultar difícil. No existen especificaciones web formales sobre cómo informar errores de JS que causan diferencias en la implementación de cada navegador. Además, ha habido muchos errores en la implementación de errores de JavaScript en los navegadores que han hecho que esto sea aún más difícil. Esta página explora estos aspectos de los errores de JS para que los futuros desarrolladores puedan manejar mejor los errores y, con suerte, los navegadores converjan en soluciones estandarizadas.

Anatomía de un error de JavaScript

Un error de JavaScript se compone de dos partes principales: el mensaje de error y el seguimiento de la pila . El mensaje de error es una cadena que describe lo que salió mal y el seguimiento de la pila describe en qué parte del código ocurrió el error. Los errores JS pueden ser producidos por el propio navegador o por el código de la aplicación.

Produciendo un error de JavaScript

El navegador puede generar un error JS cuando un fragmento de código no se ejecuta correctamente, o puede generarlo directamente mediante código.

Por ejemplo:

 var a = 3;a();

En este ejemplo, una variable que en realidad es un número no se puede invocar como función. El navegador arrojará un error como TypeError: a is not a function con un seguimiento de pila que apunte a esa línea de código.

Es posible que un desarrollador también desee generar un error en un fragmento de código si no se cumple una determinada condición previa. Por ejemplo

 si (!checkPrecondition()) {
  throw new Error("¡No cumple con la condición previa!");}

En este caso, el error será Error: Doesn't meet precondition! . Este error también contendrá un seguimiento de la pila que apunta a la línea apropiada. Los errores generados por el navegador y el código de la aplicación se pueden manejar de la misma manera.

Hay varias formas en que los desarrolladores pueden generar un error en JavaScript:

  • throw new Error('Problem description.')

  • throw Error('Problem description.') <-- equivalente al primero

  • throw 'Problem description.' <-- malo

  • throw null <-- incluso peor

Realmente no se recomienda arrojar una cadena o un valor nulo, ya que el navegador no adjuntará un seguimiento de la pila a ese error, perdiendo el contexto de dónde ocurrió ese error en el código. Es mejor generar un objeto Error real, que contendrá el mensaje de error así como un seguimiento de la pila que apunte a las líneas correctas de código donde ocurrió el error.

Mensajes de error

Cada navegador tiene su propio conjunto de mensajes que utiliza para las excepciones integradas, como el ejemplo anterior para intentar llamar a una función que no es. Los navegadores intentarán utilizar los mismos mensajes, pero como no hay ninguna especificación, esto no está garantizado. Por ejemplo, tanto Chrome como Firefox usan {0} is not a function para el ejemplo anterior, mientras que IE11 informará Function expected (en particular, también sin informar qué variable se intentó llamar).

Sin embargo, los navegadores también tienden a divergir con frecuencia. Cuando hay varias declaraciones predeterminadas en una declaración switch , Chrome arrojará "More than one default clause in switch statement" mientras que Firefox informará "more than one switch default" . A medida que se agregan nuevas funciones a la web, estos mensajes de error deben actualizarse. Estas diferencias pueden entrar en juego más adelante cuando intente gestionar los errores informados por código ofuscado.

Puede encontrar las plantillas que utilizan los navegadores para los mensajes de error en:

  • Firefox: http://mxr.mozilla.org/mozilla1.9.1/source/js/src/js.msg

  • Chrome: https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/messages.js

  • Internet Explorer: https://github.com/Microsoft/ChakraCore/blob/4e4d4f00f11b2ded23d1885e85fc26fcc96555da/lib/Parser/rterrors.h

Los navegadores producirán diferentes mensajes de error para algunas excepciones.

Formato de seguimiento de pila

El seguimiento de la pila es una descripción de dónde ocurrió el error en el código. Se compone de una serie de cuadros, donde cada cuadro describe una línea particular en el código. El fotograma superior es la ubicación donde se produjo el error, mientras que los fotogramas siguientes son la pila de llamadas a la función, o cómo se ejecutó el código para llegar al punto donde se produjo el error. Dado que JavaScript suele estar concatenado y minimizado, también es importante tener números de columna para que se pueda localizar la declaración exacta cuando una línea determinada tenga una multitud de declaraciones.

Un seguimiento de pila básico en Chrome se ve así: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9)
  at http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

Cada marco de pila consta de un nombre de función (si corresponde y el código no se ejecutó en el ámbito global), el script del que proviene y el número de línea y columna del código.

Desafortunadamente, no existe un estándar para el formato de seguimiento de la pila, por lo que difiere según el navegador.

El seguimiento de la pila de Microsoft Edge e IE 11 es similar al de Chrome, excepto que enumera explícitamente el código global: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:3)
  at Global code (http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3)

El seguimiento de la pila de Firefox se ve así: 

  throwError@http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9
  @http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

El formato de Safari es similar al formato de Firefox pero también es ligeramente diferente: 

  throwError@http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:18
  global code@http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:13

Allí se encuentra la misma información básica, pero el formato es diferente.

También tenga en cuenta que en el ejemplo de Safari, además de que el formato es diferente al de Chrome, los números de columna son diferentes a los de Chrome y Firefox. Los números de las columnas también pueden desviarse más en diferentes situaciones de error, por ejemplo en el código (function namedFunction() { throwError(); })(); , Chrome informará la columna para la llamada a la función throwError() mientras que IE11 informará el número de columna como el inicio de la cadena. Estas diferencias volverán a entrar en juego más adelante, cuando el servidor necesite analizar el seguimiento de la pila en busca de errores informados y desofuscar los seguimientos de la pila ofuscados.

Consulte https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/Stack para obtener más información sobre la propiedad de pila de los errores. Al acceder a la propiedad Error.stack, Chrome incluye el mensaje de error como parte de la pila, pero Safari 10+ no.

El formato de los seguimientos de la pila difiere según el navegador en cuanto a la forma y los números de columna utilizados.

Profundizando más, hay muchos matices para apilar formatos de seguimiento que se analizan en las secciones siguientes.

Nombrar funciones anónimas

De forma predeterminada, las funciones anónimas no tienen nombre y aparecen como una cadena vacía o como "Función anónima" en los nombres de las funciones en el seguimiento de la pila (según el navegador). Para mejorar la depuración, debe agregar un nombre a todas las funciones para asegurarse de que aparezcan en el marco de la pila. La forma más sencilla de hacerlo es asegurarse de que las funciones anónimas se especifiquen con un nombre, incluso si ese nombre no se utiliza en ningún otro lugar. Por ejemplo:

 setTimeout(nombre de funciónOfTheAnonymousFunction() {... }, 0);

Esto hará que el seguimiento de la pila vaya desde: 

at http://mknichel.github.io/javascript-errors/javascript-errors.js:125:17

a 

at nameOfTheAnonymousFunction (http://mknichel.github.io/javascript-errors/javascript-errors.js:121:31)

En Safari, esto iría desde: 

https://mknichel.github.io/javascript-errors/javascript-errors.js:175:27

a 

nameOfTheAnonymousFunction@https://mknichel.github.io/javascript-errors/javascript-errors.js:171:41

Este método garantiza que nameOfTheAnonymousFunction aparezca en el marco para cualquier código dentro de esa función, lo que facilita mucho la depuración. Consulte http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/#toc-debugging-tips para obtener más información.

Asignar funciones a una variable

Los navegadores también usarán el nombre de la variable o propiedad a la que está asignada una función si la función en sí no tiene un nombre. Por ejemplo, en

 var fnVariableName = función() {...};

Los navegadores utilizarán fnVariableName como nombre de la función en los seguimientos de la pila. 

    at throwError (http://mknichel.github.io/javascript-errors/javascript-errors.js:27:9)
    at fnVariableName (http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37)

Aún más matizado que eso, si esta variable se define dentro de otra función, todos los navegadores usarán solo el nombre de la variable como nombre de la función en el seguimiento de la pila, excepto Firefox, que usará una forma diferente que concatena el nombre de la función externa con el nombre de la variable interna. Ejemplo:

 función throwErrorFromInnerFunctionAssignedToVariable() {
  var fnVariableName = función() { lanzar nuevo Error("foo"); };
  fnNombreVariable();}

producirá en Firefox: 

throwErrorFromInnerFunctionAssignedToVariable/fnVariableName@http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37

En otros navegadores, esto se vería así: 

at fnVariableName (http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37)

Firefox utiliza texto de marco de pila diferente para funciones definidas dentro de otra función.

propiedad displayName

El nombre para mostrar de una función también se puede establecer mediante la propiedad displayName en todos los navegadores principales, excepto IE11. En estos navegadores, el nombre para mostrar aparecerá en el depurador de devtools, pero en todos los navegadores excepto Safari, no se usará en los seguimientos de la pila de errores (Safari se diferencia del resto porque también usa el nombre para mostrar en el seguimiento de la pila asociado con un error).

 var someFunction = function() {};someFunction.displayName = " # Una descripción más larga de la función.";

No existe una especificación oficial para la propiedad displayName, pero es compatible con los principales navegadores. Consulte https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/displayName y http://www.alertdebugging.com/2009/04/29/building-a-better -javascript-profiler-with-webkit/ para obtener más información sobre displayName.

IE11 no admite la propiedad displayName.

Safari usa la propiedad displayName como nombre del símbolo en los seguimientos de la pila de errores.

Capturar seguimientos de pila de forma programada

Si se informa un error sin un seguimiento de la pila (consulte más detalles sobre cuándo sucedería esto a continuación), entonces es posible capturar un seguimiento de la pila mediante programación.

En Chrome, esto es realmente fácil de hacer usando la API Error.captureStackTrace . Consulte https://github.com/v8/v8/wiki/Stack%20Trace%20API para obtener más información sobre el uso de esta API.

Por ejemplo:

 función ignorarEstaFunciónInStackTrace() {
  var err = nuevo Error();
  Error.captureStackTrace (err, ignoreThisFunctionInStackTrace);
  devolver error.pila;}

En otros navegadores, también se puede recopilar un seguimiento de la pila creando un nuevo error y accediendo a la propiedad de la pila de ese objeto:

 var err = nuevo Error('');return err.stack;

Sin embargo, IE10 solo completa el seguimiento de la pila cuando realmente se produce el error:

 intentar {
  lanzar nuevo Error('');} catch (e) {
  devolver e.stack;}

Si ninguno de estos enfoques funciona, entonces es posible crear un seguimiento de pila aproximado sin números de línea o columnas iterando sobre el objeto arguments.callee.caller ; sin embargo, esto no funcionará en el modo estricto de ES5 y no es un enfoque recomendado.

Seguimientos de pila asíncronos

Es muy común que se inserten puntos asincrónicos en el código JavaScript, como cuando el código usa setTimeout o mediante el uso de Promesas. Estos puntos de entrada asíncronos pueden causar problemas para los seguimientos de la pila, ya que provocan que se forme un nuevo contexto de ejecución y el seguimiento de la pila comienza desde cero nuevamente.

Chrome DevTools admite seguimientos de pila asíncronos o, en otras palabras, asegurarse de que el seguimiento de pila de un error también muestre los fotogramas que ocurrieron antes de que se introdujera el punto asíncrono. Con el uso de setTimeout, esto capturará quién llamó a la función setTimeout que finalmente produjo un error. Consulte http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/ para obtener más información.

Un seguimiento de pila asíncrono se verá así: 

  throwError	@	throw-error.js:2
  setTimeout (async)		
  throwErrorAsync	@	throw-error.js:10
  (anonymous function)	@	throw-error-basic.html:14

Los seguimientos de pila asíncronos solo se admiten en Chrome DevTools en este momento, solo para las excepciones que se generan cuando DevTools está abierto. Los seguimientos de pila a los que se accede desde objetos Error en el código no tendrán el seguimiento de pila asíncrono como parte del mismo.

Es posible realizar un polirrelleno de seguimientos de pila asíncronos en algunos casos, pero esto podría causar un impacto significativo en el rendimiento de su aplicación, ya que capturar un seguimiento de pila no es barato.

Solo Chrome DevTools admite de forma nativa seguimientos de pila asíncronos.

Nombrar scripts en línea y evaluación

Los seguimientos de pila para el código que fue evaluado o insertado en una página HTML utilizarán la URL de la página y los números de línea/columna para el código ejecutado.

Por ejemplo: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9)
  at http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

Si estos scripts en realidad provienen de un script que se incluyó por motivos de optimización, entonces la URL, los números de línea y de columna serán incorrectos. Para solucionar este problema, Chrome y Firefox admiten la anotación //# sourceURL= (Safari, Edge e IE no). La URL especificada en esta anotación se utilizará como URL para todos los seguimientos de la pila, y el número de línea y columna se calculará en relación con el inicio de la etiqueta