Nuestro producto inserta un script en los sitios web de los clientes, como una ventana de chat en vivo.
A menudo, los sitios web de los clientes tienen javascript con errores que también detiene nuestro código (el navegador detiene la ejecución cuando se encuentran errores). ¿Hay alguna forma de hacer que nuestro código aún se ejecute aunque haya errores en la consola sobre cosas como métodos o variables no definidos?
Gracias por tu ayuda.
chris tonkinson
La respuesta corta es que realmente no puedes.
“Solución” #1: Puede insistir en que SU código de terceros se ejecute antes que el de cualquier otra persona. En la mayoría de los casos, esto no es posible o incluso deseable.
“Solución” #2: Podría insistir en que los ingenieros de la primera parte envuelvan todo el código de la tercera parte en try/catch bloques Pero, esta solución realmente no le ofrece ninguna garantía, porque con mucha frecuencia las bibliotecas de terceros adjuntan <script> etiquetas a la página – estas no caerían bajo la “jurisdicción” de la try/catch ámbito que incluye el código que creó esta/estas etiquetas.
“Solución” #3: Podrías construir TU aplicación completamente dentro del alcance de un <iframe>, evitando así el problema por completo. Desafortunadamente, incluso si es muy inteligente, rápidamente se encontrará con infracciones entre dominios, restricciones de cookies de terceros y similares. Es muy probable que esto no te funcione.
“Solución” #4: Podría explicar el problema a su cliente y pedirle que exija que el otro código de terceros se ejecute sin problemas. Digo que esta es una “solución” porque, francamente, no es una “solución” a su pregunta si su pregunta es cómo evitar hacer exactamente esto.
Desafortunadamente, la opción #4 es su mejor apuesta. Puede ayudar si observa que otras bibliotecas de terceros “se rompen” de la misma manera: puede decirle a su cliente “oye, no soy solo yo: X, Y y Z también están ‘rotos’ debido a
-
Así que envolviendo las funciones en un ‘cierre’ como
$(function() { function myLibraryFunction() {...} }¿No ayudará y aislará la ejecución del código como aísla los nombres de las funciones y las variables?– Cloe
16 oct 2017 a las 15:21
-
Errores no detectados lanzados en un script (
<script></script>) solo debe abortar ese script y no otros scripts en la página. Incluso entonces, podría haber una recuperación/reintento… por ejemplo, si unsetTimeoutse llamó antes de que ocurriera el error no detectado que permitía verificar el estado, reiniciar, volver a intentarlo, etc. t hacer un buen trabajo de captura/manejo de errores para varios scripts de terceros que la gestión de etiquetas fue responsable de cargar.– mattpr
12 de septiembre de 2022 a las 13:24
Jason Kulatunga
Como han dicho otros, continuar después de un error puede no ser lo mejor, pero puedes probar esto:
function ignoreerror()
{
return true
}
window.onerror=ignoreerror();
Más detalles aquí
El evento onerror se activa cada vez que se produce un error de JavaScript (dependiendo de la configuración de su navegador, es posible que aparezca un cuadro de diálogo de error). El evento onerror está adjunto al objeto ventana, un lugar bastante inusual para refugiarse, pero por una buena razón. Se adjunta de esta manera para que pueda monitorear todos los errores de JavaScript en una página, incluso aquellos en la sección de la página.
Opera tiene una página con más detalles
Browsers supporting window.onerror
Chrome 13+
Firefox 6.0+
Internet Explorer 5.5+
Opera 11.60+
Safari 5.1+
-
Tenga en cuenta los documentos de MDN: “Tenga en cuenta que algunos/muchos eventos de error no activan window.onerror, debe escucharlos específicamente”. (desarrollador.mozilla.org/en/DOM/window.onerror)
–Chris Tonkinson
31 de mayo de 2012 a las 1:24
-
Descubrí que window.onerror aún hace que el código deje de ejecutarse. Todo lo que parece hacer return true es suprimir la aparición de la excepción en la consola. El siguiente código (probado en Chrome 42 e IE 10) ilustra mi punto: window.onerror = function(){return true;}; vars = “”; s.push(“H”); alerta(“prueba”); El error se suprime pero nunca se alcanza el código de alerta.
–Scott Marcus
3 sep 2015 a las 18:57
-
Usando
onerrorreturn true;oaddEventListener.preventDefault()simplemente evita iniciar sesión en la consola. Un error no detectado siempre aborta el SCRIPT ACTUAL. La clave es separar su código en un BLOQUE de script separado (por ejemplo,<script></script>). Es probable que el problema sea que su código se cargue mediante un solo script de “administración de etiquetas” que tiene errores o no aísla los errores de los scripts cargados… así que cuando ocurre un error, no se maneja y no obtienen una oportunidad de cargar.– mattpr
12 de septiembre de 2022 a las 13:19
No puedes desde tu código, necesitan usar try/catch por piezas de guión cuestionables.
Shaz
Podría pedirles que inserten un iframe en su página en lugar de intentar inyectar código usando un script etiqueta así: http://jsfiddle.net/EzMGD/ Observe cómo el script arroja un error, pero aún podemos ver el contenido en el iframe. El iframe debería ayudar a usar las variables de los demás, si corresponde.
<script>
MeaningOfLife();
</script>
<iframe src="http://bing.com"></iframe>
O inyecta el código para que sea el primero o el último script.
Bueno, para mí eso funciona bien:
element = document.querySelector('.that-pretty-element');
if (element != null) {
element.onclick = function () {
alert(" I'm working beibi ;) ");
}
}
querySelector() devoluciones falseentonces, podemos verificar con if's
Teóricamente, no a menos que ejecute su secuencia de comandos antes que cualquier otra cosa en la página (lo que generalmente no es posible, o incluso deseable).
–Chris Tonkinson
31 de mayo de 2012 a las 0:25
Algo así como cuando falla el motor del avión, ¿no hay una manera de hacer que siga funcionando?
–CD Smith
31 de mayo de 2012 a las 0:25
No creo que debas cuidar los sitios de los clientes. Si sus sitios tienen errores, es su propio problema. También los motivaría a corregir el código en lugar de agregar una solución tras otra.
– Fabricio Matté
31 de mayo de 2012 a las 0:27
@AlfalfaStrange cerca, pero esto es menos parecido a una falla general y más parecido a una explosión real. 🙂 +1
–Chris Tonkinson
31 de mayo de 2012 a las 0:27
@D3mon-1stVFW: ¿Lo dices en serio? ¿Un applet? Tenemos 2012, no 2000. Pero sí, no pierdas el tiempo haciendo que tus cosas funcionen en sitios rotos. Si lo quieren, deberían arreglar sus cosas.
– ThiefMaster
31 de mayo de 2012 a las 0:51