javascript - una - salto de linea consola chrome
¿Cómo se envían mensajes de consola y errores para alertar? (3)
Me gustaría pasar los errores a una alerta para advertir al usuario que cometieron un error en su código, incluso si no tienen la consola abierta.
var doc=(frame.contentWindow.document || obj.contentDocument|| obj.contentWindow);
var head = doc.getElementsByTagName(''head'')[0];
var scriptElement = doc.createElement(''script'');
scriptElement.setAttribute(''type'', ''text/javascript'');
scriptElement.text = scripts;
try{
head.appendChild(scriptElement);
}
catch(e){ alert("error:"+e.message +" linenumber:"+e.lineNumber);}
El appendChild arroja un error cuando los scripts contienen un error. Sin embargo, va directamente a la consola, y quiero que se muestre en una alerta, porque es para niños y es posible que no revisen la consola. El bloque try catch no detecta el error. Lo intenté con eval (scripts).
try{
eval(scripts);} catch(e){ alert("error:"+e.message +" linenumber:"+e.lineNumber);}
esto funciona, pero significa que el código se ejecuta dos veces, y eso es muy inconveniente en algunos casos.
Intenté el parche parcheando la consola.error:
console.log=function(){alert("taking over the log");}
console.error=function(){alert("taking over the log");}
pero eso solo funciona cuando literalmente uso console.error. No cuando se produce un error real. ¿Qué función envía el error a la consola en el caso de un error real, si no es console.error? y ¿puedo acceder a él y cambiarlo? ¿Algunas ideas? La ayuda sería muy apreciada. Gracias Jenita
Mientras try ... catch
funcionará en el código que ejecuta el script inicialmente, ya que Jenita dice que no detectará los errores de sintaxis, y tampoco detectará los errores lanzados por las funciones de devolución de llamada que se ejecutarán más tarde (mucho después del try-catch ha terminado). Eso significa que no hay errores de ninguna función pasada a setTimeout
o addEventListener
.
Sin embargo, puedes probar un enfoque diferente. Registre un detector de errores en la ventana.
window.addEventListener("error", handleError, true);
function handleError(evt) {
if (evt.message) { // Chrome sometimes provides this
alert("error: "+evt.message +" at linenumber: "+evt.lineno+" of file: "+evt.filename);
} else {
alert("error: "+evt.type+" from element: "+(evt.srcElement || evt.target));
}
}
Se llamará a esto cuando se lanza una excepción desde una función de devolución de llamada. Pero también se activará en los errores DOM generales, como las imágenes que no se cargan, que pueden no interesarle.
También debe activar los Errores de sintaxis, pero solo si pudo ejecutarse primero, por lo que debe colocarlo en un script separado del que pueda contener errores tipográficos. (Un error de sintaxis más adelante en una secuencia de comandos evitará la ejecución de líneas válidas en la parte superior de la misma secuencia de comandos.)
Desafortunadamente, nunca encontré la manera de obtener un número de línea del evt
en Firefox. (Editar: Empuje alrededor, creo que podría estar allí ahora).
Descubrí esto al tratar de escribir FastJSLogger , un registrador in-page que utilicé cuando los devtools del navegador eran algo lentos.
Desesperado por capturar números de línea, comencé a experimentar con wrappers para setTimeout
y addEventListener
que volverían a introducir try-catch alrededor de esas llamadas. Por ejemplo:
var realAddEventListener = HTMLElement.prototype.addEventListener;
HTMLElement.prototype.addEventListener = function(type,handler,capture,other){
var newHandler = function(evt) {
try {
return handler.apply(this,arguments);
} catch (e) {
alert("error handling "+type+" event:"+e.message +" linenumber:"+e.lineNumber);
}
};
realAddEventListener.call(this,type,newHandler,capture,other);
};
Obviamente, esto debe hacerse antes de que se registren los detectores de eventos, y posiblemente incluso antes de que se carguen las bibliotecas como jQuery, para evitar que capten una referencia al addEventListener
real antes de que podamos reemplazarlo.
Ok, la forma menos elegante pero altamente eficiente de hacerlo es ''refactorizar'' tus funciones de consola innatas. Básicamente, cualquier error o advertencia que obtenga se imprime allí mediante una función de JavaScript que es bastante similar a la función familiar console.log (). Las funciones de las que estoy hablando son console.warn (), console.info () y console.error (). ahora vamos a ''mapear'' lo que hace cada uno de ellos:
//remap console to some other output
var console = (function(oldCons){
return {
log: function(text){
oldCons.log(text);
//custom code here to be using the ''text'' variable
//for example: var content = text;
//document.getElementById(id).innerHTML = content
},
info: function (text) {
oldCons.info(text);
//custom code here to be using the ''text'' variable
},
warn: function (text) {
oldCons.warn(text);
//custom code here to be using the ''text'' variable
},
error: function (text) {
oldCons.error(text);
//custom code here to be using the ''text'' variable
}
};
}(window.console));
//Then redefine the old console
window.console = console;
Ahora, en general, desaconsejaría usar algo como esto en la producción y limitarlo a la depuración, pero como estás tratando de desarrollar una funcionalidad que muestre la salida de la consola, las líneas son borrosas allí, así que lo dejo Depende de usted.
Podría envolver el script en su propio try / catch, algo así como:
var doc=(frame.contentWindow.document || obj.contentDocument|| obj.contentWindow);
var head = doc.getElementsByTagName(''head'')[0];
var scriptElement = doc.createElement(''script'');
scriptElement.setAttribute(''type'', ''text/javascript'');
scriptElement.text = "try{"+scripts+"}catch(e){console.error(e);alert(''Found this error: '' + e +''. Check the console.'')}"
head.appendChild(scriptElement);