2011-10-26 9 views
14

Me gustaría detectar todos los errores de JavaScript del lado del cliente en nuestro sitio y registrarlos. ¿Cuáles son algunas de las mejores prácticas para hacer esto?¿La mejor práctica para informar errores del cliente con window.onerror?

Pensamientos:

  • puedo añadir fácilmente un controlador /log/ a nuestra aplicación web, analisis de sintaxis GET/POST y parámetros utilizar nuestro sistema de registro existente en el lado del servidor. ¿Es eso demasiado obvio?
  • ¿Funciona window.onerror en todos lados? ¿Qué pasa si ocurre un error en el controlador?
  • ¿Debo adjuntar una etiqueta <img> a la página o hacer una XmlHttpRequest? ¿Qué pasa si el XHR falla?
  • ¿Qué pasa con las imágenes rotas y las fallas jQuery Ajax? ¿Puedo detectarlas también?
+0

¡Gracias a todos! Bounty va a dgvid con la mayor cantidad de información. La respuesta aceptada va para Zoran con el superconjunto de información. –

Respuesta

6

Todas las sugerencias hechas por Jbecwar y dgvid son frescos, yo añadiría:

  • nota que Opera no soporta evento de error ver quirksmode error event
  • recolección stacktraces con stacktrace.js podría ayudar a solucionar errores
  • si el error el manejador no puede enviar el informe de errores al lado del servidor, recurrir al uso de cookies: configurar cookies para errors.yourdomain.com con informe de error codificado base64 (¿comprimido?) y solicitar imágenes vacías de 1x1 píxeles de ese dominio en cada página
  • o utiliza HTML5 de almacenamiento local y subirlo cuando se puede
+0

Actually Opera lo admite desde 11.60 (fuente: http://dev.opera.com/articles/view/better-error-handling-with-window-onerror/) – RelaXNow

+0

StackTrace.js aparentemente ahora está en http: // stacktracejs .com. –

3

El controlador de registro parece ser una buena idea, pero limitaría el número de informes o intentos que hace el informe. Por ejemplo, no desea que el periodista tenga un error y luego intente informarlo una y otra vez. Además, si tiene un cliente malo o un aumento en el tráfico, no quiere registrar demasiado.

Además, window.onerror no funcionará para iframes y lo haría el xmlhttprequest, es lo que no quiere meterse con el DOM si ya tiene problemas

TL; DR; Limite las solicitudes del lado del cliente y aplique límites en el servidor. window.onerror no es bueno para iframes, y usa xmlhttprequest.

3

Como sugiere Jbecwar, el controlador de registro es una buena idea, pero debe tener cuidado con una condición en la que trate de llamar al controlador de registro para informar un error al contactar al controlador de registro. Si el navegador pierde su conexión con el servidor, no podrá volver a registrarlo en el servidor.

Puede detectar un error de carga img al asociar un controlador de errores al elemento img y luego establecer su atributo src. Por ejemplo, usando jQuery:

$("img#my-image").error(onImgError).prop("src", "images/my-image.jpg"); 

Usted no recibirá toda la información de esa manera, sólo el hecho de que se ha producido un error al intentar cargar el elemento especificado.

Puede manejar las fallas en las solicitudes de jQuery.ajax al incluir una función de devolución de llamada de error en el objeto de configuración pasado a $ .ajax. Asegúrese de ajustar el código en las funciones de devolución de llamada correcta y de error en try-catch.

En general, querrá proteger su código con bloques try-catch para que pueda detectar y registrar errores. Manejar window.onerror debería ser un último recurso, por las cosas que se filtran.

En su controlador window.onerror, ajuste todo en un bloque try-catch y asegúrese de que no lanzará desde el código en el bloque catch (usando try-catch anidados, si es necesario).

3

recientemente hemos comenzado a comunicar errores no controlados como de páginas vistas al google-analytics. La idea básica es que un manejador de window.onerror convierta la información de error (ruta de archivo de script, número de línea y mensaje de error) en un url de página de error virtual y lo informe como una vista de página. Puede aplicar la lógica a cualquier mecanismo de seguimiento de página.

El código simple que usamos está disponible en GitHub en https://github.com/shyam-habarakada/js-watson

Con todo el poder analítico de Google Analytics, y esta técnica sencilla, hemos tenido un gran éxito en la identificación de los errores frecuentes y críticos y ha sido capaz resolverlos rápidamente También puede usar el poder de GA para analizar tendencias en errores generales, errores específicos en archivos específicos, etc. etc. Altamente recomendado.

Cuestiones relacionadas