No hay una gran trato que puede hacer sobre los errores de JavaScript en el extremo del cliente. Puede interceptar window.onerror
y usarlo en AJAX un informe posterior, pero:
(a) no es compatible con WebKit u Opera. Para la captura de todos los errores que tendría que envolver cada ejecución directa, evento y punto de entrada de tiempo de espera en un try { ... }
, que es muy desordenado y le da aún menos información que el manejador onerror
.
(b) es probable que se inunde con informes de errores que no puede hacer nada, con poca depuración posible debido a la falta de información. Usted puede ser capaz de salirse con la suya en una aplicación que sólo se accede por los clientes que conoces, pero en un sitio de acceso público, una gran cantidad de errores va a ser falsa. Cosas causadas por factores como:
conexiones a sitios que alojan scripts o AJAX que falla o está bloqueado por firewalls;
configuración de seguridad inesperada (los navegadores tienen opciones para bloquear muchas interfaces arbitrariamente);
complementos de navegador rotos, scripts de GreaseMonkey, proxies de filtrado y herramientas falsas de "Seguridad de Internet" jugando con su código;
agentes incompatibles que se comportan de manera extraña, como navegadores móviles (especialmente el espantoso IEMobile) y, si tienen acceso, bots de navegador automático;
muchos errores causados por contenido de terceros como anuncios, si tiene alguno.
Una vez más, para una aplicación de uso limitado que puede contactar directamente a cualquier usuario que está experimentando problemas, podría ser de utilidad, pero para un sitio utilizado por el público en general es un no-arrancador.
Lo mejor es utilizar la "mejora progresiva" para garantizar que su aplicación aún funcione cuando falla JavaScript.
Solo asegúrese de que el código de manejo del onerror sea a prueba de balas ;-) – spender