javascript - provocar - try and catch java script

Manejo de excepciones JavaScript

Question

¿Cuál es la mejor técnica para detectar TODAS las excepciones lanzadas dentro de JavaScript?

Obviamente, la mejor técnica es usar try ... catch. Pero con devoluciones de llamada ansincrónicas y demás, eso puede ser complicado.

Sé que los navegadores IE y Gecko son compatibles con window.onerror, pero ¿qué hay de Opera y Safari?

Aquí hay un montón de casos de prueba en los que me gustaría tener una solución central de manejo de excepciones para:

// ErrorHandler-Test1
var test = null;
test.arg = 5;
// ErrorHandler-Test2
throw (new Error("Hello"));
// ErrorHandler-Test3
throw "Hello again";
// ErrorHandler-Test4
throw {
myMessage: "stuff",
customProperty: 5,
anArray: [1, 2, 3]
};
// ErrorHandler-Test5
try {
var test2 = null;
test2.arg = 5;
} catch(e) {
ErrorHandler.handleError(e);
}
// ErrorHandler-Test6
try {
throw (new Error("Goodbye"));
} catch(e) {
ErrorHandler.handleError(e);
}
// ErrorHandler-Test7
try {
throw "Goodbye again";
} catch(e) {
ErrorHandler.handleError(e);
}
// ErrorHandler-Test8
try {
throw {
myMessage: "stuff",
customProperty: 5,
anArray: [1, 2, 3]
};
} catch(e) {
ErrorHandler.handleError(e);
}

Si piensa en algún otro caso de prueba, por favor mencionarlo. Varios de estos casos mencionan un método ErrorHandler.handleError. Esta es solo una guía sugerida cuando se usa try ... catch.

Answer 1

Capture todas las excepciones con su propio manejador de excepciones y use instanceof.

$("inuput").live({
click : function (event) {
try {
if (somethingGoesWrong) {
throw new MyException();
}
} catch (Exception) {
new MyExceptionHandler(Exception);
}
}
});
function MyExceptionHandler(Exception) {
if (Exception instanceof TypeError ||
Exception instanceof ReferenceError ||
Exception instanceof RangeError ||
Exception instanceof SyntaxError ||
Exception instanceof URIError ) {
throw Exception; // native error
} else {
// handle exception
}
}

MyExcetpionHandler lanzará un error nativo ya que no hay un bloque try-catch.

Visite http://www.nczonline.net/blog/2009/03/10/the-art-of-throwing-javascript-errors-part-2/

Answer 2

Con un poco de trabajo es posible obtener stacktraces razonablemente completos en todos los navegadores.

Modern Chrome y Opera (es decir, cualquier cosa basada en el motor de renderizado Blink) son totalmente compatibles con las especificaciones de borrador de HTML 5 para ErrorEvent y window.onerror . En ambos navegadores puedes usar window.onerror o (increíblemente) enlazar al evento ''error'' correctamente:

// Only Chrome & Opera pass the error object.
window.onerror = function (message, file, line, col, error) {
console.log(message, "from", error.stack);
// You can send data to your server
// sendData(data);
};
// Only Chrome & Opera have an error attribute on the event.
window.addEventListener("error", function (e) {
console.log(e.error.message, "from", e.error.stack);
// You can send data to your server
// sendData(data);
})

Lamentablemente, Firefox, Safari e IE aún existen y tenemos que apoyarlos también. Como stacktrace no está disponible en window.onerror tenemos que hacer un poco más de trabajo.

Resulta que lo único que podemos hacer para obtener stacktraces de los errores es ajustar todo nuestro código en un bloque try{ }catch(e){ } y luego mirar e.stack. Podemos facilitar el proceso con una función llamada wrap que toma una función y devuelve una nueva función con un buen manejo de errores.

function wrap(func) {
// Ensure we only wrap the function once.
if (!func._wrapped) {
func._wrapped = function () {
try{
func.apply(this, arguments);
} catch(e) {
console.log(e.message, "from", e.stack);
// You can send data to your server
// sendData(data);
throw e;
}
}
}
return func._wrapped;
};

Esto funciona. Cualquier función que envuelva manualmente tendrá un buen manejo de errores.

Puede enviar datos usando la etiqueta de imagen de la siguiente manera

function sendData(data) {
var img = newImage(),
src = http://yourserver.com/jserror + ''&data='' + encodeURIComponent(JSON.stringify(data));
img.crossOrigin = ''anonymous'';
img.onload = function success() {
console.log(''success'', data);
};
img.onerror = img.onabort = function failure() {
console.error(''failure'', data);
};
img.src = src;
}

Sin embargo, tiene que hacer back-end para recopilar los datos y el front-end para visualizar los datos.

En Atatus , estamos trabajando para resolver este problema. Más que el seguimiento de errores, Atatus proporciona una supervisión real del usuario.

Pruébalo Atatus

Descargo de responsabilidad: soy un desarrollador web en Atatus.

Answer 3

En realidad, el enfoque jquery no es tan malo. Ver:

http://docs.jquery.com/Events/error#fn

y:

$(window).error(function(msg, url, line){
$.post("js_error_log.php", { msg: msg, url: url, line: line });
});

Answer 4

Es cierto que con los navegadores modernos, al enrutar window.onerror para los errores que llegan hasta la cima junto con la adición de manejadores de eventos jQuery para los errores Ajax capturará prácticamente todos los objetos Error arrojados en su código de cliente. Si está configurando manualmente un controlador para window.onerror, en navegadores modernos esto se hace con window.addEventListener(''error'', callback) , mientras que en IE8 / 9 necesita llamar a window.attachEvent(''onerror'', callback)

Tenga en cuenta que debe considerar el entorno en el que se están manejando estos errores y la razón para hacerlo. Una cosa es atrapar tantos errores como sea posible con sus stacktraces, pero el advenimiento de las modernas herramientas de desarrollo F12 resuelve este caso de uso al implementar y depurar localmente. Los puntos de interrupción, etc., le darán más datos de los disponibles por los manejadores, especialmente para los errores arrojados por bibliotecas de terceros que fueron cargadas de solicitudes CORS. Debe seguir pasos adicionales para indicar al navegador que proporcione estos datos.

La cuestión clave es proporcionar estos datos en producción, ya que sus usuarios tienen la garantía de ejecutar una gama mucho más amplia de navegadores y versiones de las que posiblemente pueda probar, y su sitio / aplicación se dividirá de maneras inesperadas, sin importar cuánto QA arroje a eso.

Para manejar esto, necesita un rastreador de errores de producción que detecta cada error que se produce en los navegadores de su usuario, ya que usan su código, y los envía a un punto final donde los datos pueden ser vistos y utilizados para corregir los errores a medida que ocurren . En Raygun (descargo de responsabilidad: trabajo en Raygun) hemos dedicado un gran esfuerzo a proporcionar una gran experiencia para esto, ya que hay muchas trampas y problemas que considerar que una implementación ingenua se perderá.

Por ejemplo, es probable que agrupe y minimice sus activos JS, lo que significa que los errores arrojados desde el código minificado tendrán trazas acumuladas de basura con nombres de variables mutilados. Para esto, necesita su herramienta de compilación para generar mapas de origen (recomendamos UglifyJS2 para esta parte de la interconexión), y su rastreador de errores para aceptar y procesar estos, convirtiendo las stacktraces destrozadas nuevamente en legibles para humanos. Raygun hace todo esto de la caja, e incluye un punto final API para aceptar los mapas fuente a medida que son generados por su proceso de compilación. Esta es la clave, ya que deben mantenerse como no públicos, de lo contrario, cualquiera podría desmenuzar su código, negando su propósito.

La biblioteca de cliente de raygun4js también viene con window.onerror para los navegadores modernos y heredados, así como jQuery hooks out-of-the-box, por lo que para configurar esto solo necesita agregar:

<script type="text/javascript" src="//cdn.raygun.io/raygun4js/raygun.min.js" </script> <script> Raygun.init(''yourApiKey'').attach(); </script>

También hay una gran cantidad de funcionalidades integradas que incluyen la capacidad de mutar la carga de error antes de enviarla, agregar etiquetas y datos personalizados, metadatos sobre el usuario que vio el error. También elimina la molestia de obtener buenos seguimientos de pila de los scripts CORS de terceros antes mencionados, lo que resuelve el temido "Error de secuencia de comandos" (que no contiene ningún mensaje de error ni rastro de pila).

Un problema más importante es que debido a la gran cantidad de público en la web, su sitio generará miles de instancias duplicadas de cada error. Un servicio de seguimiento de errores como Raygun tiene inteligencia para distribuirlos en grupos de error para que no se atasque en una avalancha de notificaciones y le permita ver cada error real listo para ser reparado.

Answer 5

Si utiliza una biblioteca como jQuery para asignar todos sus controladores de eventos, puede usar una combinación de window.onerror y envolviendo el código del manejador de eventos jQuery y en la función ready con una función de manejo de errores (vea: JavaScript Error Tracking: Why window.onerror No es suficiente ).

• window.onerror : detecta todos los errores en IE (y la mayoría de los errores en Firefox), pero no hace nada en Safari y Opera.
• Controladores de eventos jQuery: detecta errores de eventos jQuery en todos los navegadores.
• Función jQuery ready: detecta errores de inicialización en todos los navegadores.

Answer 6

También estaba buscando manejo de errores y stacktrace y registro para las acciones del usuario, esto es lo que encontré espero que esto también te ayude https://github.com/jefferyto/glitchjs

Answer 7

WebKit (Safari, Chrome, etc.) ahora parece ser compatible con onerror .

onerror original: hasta donde yo sé, WebKit / Safari no admite el evento onerror . Lo cual es una maldita vergüenza.

Answer 8

try-catch no siempre es la mejor solución. Por ejemplo, en Chrome 7.0, pierde el buen seguimiento de la pila en la ventana de la consola. Retirar la excepción no ayuda. No conozco ninguna solución que preserve los rastros de pila y le permita reaccionar en caso de excepción.