JavaScript try/catch: ¿errores o excepciones?

Question

OK. Puede que esté rompiendo pelos aquí, pero mi código no es consistente y me gustaría hacerlo. Pero antes de hacerlo, quiero asegurarme de ir por el camino correcto. En la práctica esto no importa, pero esto me ha estado molestando por un tiempo así que pensé en preguntarle a mis compañeros ...

Cada vez que uso una declaración try... catch, en el bloque catch siempre registro un mensaje a mi consola interna. Sin embargo, mis mensajes de registro no son consistentes. O bien se parecen:

catch(err) { 
DFTools.console.log("someMethod caught an error: ",err.message); 
... 

o:

catch(ex) { 
DFTools.console.log("someMethod caught an exception: ",ex.message); 
... 

Obviamente las funciones de código adecuadamente de cualquier manera pero está empezando a molestarme que a veces me refiero a "errores" y, a veces a "excepciones". Como dije, tal vez estoy dividiendo los pelos, pero ¿cuál es la terminología adecuada de? "Excepción" o "Error"?

Answer 1

Esto es un poco subjetivo, pero para mí un error es cuando alguien o algo hace algo mal, incorrecto o no válido. Podría ser un error de sintaxis, un error lógico, un error de lectura, un error del usuario o incluso un error social. Es un concepto abstracto.

Una excepción, por otro lado, es un objeto que se crea y arroja cuando se produce una determinada condición en el código. Puede o no corresponder a un error conceptual. Entonces, para mí, la nomenclatura adecuada es "excepción".

Answer 2

Lo que se obtiene en un bloque Catch es una excepción, por lo que el nombre como una excepción ...

Si se trata de un error - Puedo manejarlo en mi código & lo general no se esperaba verlo en el bloque de captura

HTH.

Answer 3

La excepción es algo que puede esperar, por ejemplo, en un intento de abrir un archivo puede enfrentar una "excepción de archivo no encontrado". Por otro lado, los errores son algo que puede que no veas venir como la pila sobre el flujo o la memoria insuficiente.

Una excepción es una salida lógica alternativa de una función que no produce un resultado lógico. Una excepción también permite una mejor explicación de por qué existe de esta manera. Para la apertura de archivos, de nuevo, un manejador de archivo es un resultado lógico y si el archivo no existe (una posible excepción) o es una carpeta, no un archivo (otra posible excepción).

Answer 4

En JavaScript se llama Error Catching. Entonces, le sugiero que use el error en lugar de la excepción. Deje la elección en el medio usando "e". Como en los ejemplos de Mozilla. Mozilla Core JavaScript 1.5 Reference

Answer 5

El ECMAScript specification los llama excepciones. Es posible que desee hacer lo mismo.

Para continuar con su registro más informativo:

catch(ex) { 
    DFTools.console.log("someMethod caught an exception of type " 
     + ex.name + ": ", ex.message); 

También puede ser que desee tener en cuenta que las excepciones (por desgracia) pueden ser de cualquier tipo, por lo que no necesariamente tienen name y message propiedades:

catch(ex) { 
    if (ex.message && ex.name) {   
     DFTools.console.log("someMethod caught an exception of type " 
      + ex.name + ": ", ex.message); 
    } else /* deal with it somehow */ 

Como esto está empezando a mirar bastante engorroso repetir en todas partes, es posible que desee capturar en una función:

function logExceptions(methodName, action) { 

    try { 

     action(); 

    } catch (ex) { 
     if (ex.message && ex.name) {   
      DFTools.console.log("someMethod caught an exception of type " 
       + ex.name + ": ", ex.message); 
     } else { 
      DFTools.console.log("someMethod caught a poorly-typed exception: " + ex); 
     } 
    } 
} 

Ahora usted puede decir:

logExceptions(function() { 

    // do some risky stuff... 

}); 

Answer 6

RENUNCIA DE MAYOR: No considero que hay una respuesta "correcta" a esta. Las opiniones expresadas aquí son subjetivas y personales. Lo que es más es que las ideas que estoy a punto de abrazar solo son útiles si vas a hacer cosas diferentes con diferentes, ejem, fallas ... como si usaras un sistema según la respuesta informativa de Daniel Earwicker. Con eso en mente:

Yo sostengo que "una EXCEPCIÓN es excepcional". Un ERROR es menos inesperado.

renuncia: El siguiente pseudo-código no es bueno; simplemente sirve como el caso mínimo en que podría pensar para ilustrar mi punto.

nota: en este experimento, GetFile devuelve UNDEFINED si no puede encontrar el archivo especificado.

function AlwaysGetFile(name){ 
    var file = null; 
    if(FileExists(name)){ 
     file = GetFile(name); 
     if(typeof file === "undefined"){ 
      throw new "couldn't retrieve file" EXCEPTION 
     } 
    } 
    else{ 
     throw new "file does not exist" ERROR 
    } 
    return file; 
} 

En el caso de que un consumidor llama GetFileOrThrow con un nombre de archivo que no existe, se producirá un error. En mi opinión, la distinción es que el código de nivel superior (o la entrada del usuario) está haciendo algo mal ... esta función debe pasar un ERROR en la línea hacia ese código de nivel superior que puede decidir qué hacer con este resultado. Considerarlo como esto ... esta función estaría diciendo a cualquiera de las funciones que consumen:

Look, my friend, I know what's going on here: it is an ERROR to request BobAccounts.xml, so don't do it again! Oh, and if you think you now know what might have gone wrong (having abused me), go ahead and try to recover from it!

Consideremos ahora el caso de que esta función toma el nombre, comprueba que el archivo existe y luego por alguna razón no puede recuperarlo. Esta es una situación diferente. Algo realmente inesperado ha sucedido. Además, el código de consumo no es culpa de. Ahora queremos realmente esta función para decir a cualquiera de las funciones que consumen:

Oh fiddlesticks! Sorry about this, I humbly beg your pardon but something EXCEPTIONAL that I don't really understand has gone wrong. I don't think that your request for BobAccounts.xml was unreasonable... and I know I should be fulfilling it for you. Since I'm lower level code than you, I really ought to know what's going on... but I don't... and since you've less chance than me of understanding this EXCEPTIONAL situation, I think you'd probably best just stop what you're doing and let this message go all the way to the top... I mean, there is something seriously fishy going on here.

así que supongo que mi resumen es el siguiente: si el error ocurrió en una mayor código de pedido (que se aprobaron los datos erróneos) generará un error. Si el error ocurrió en un código de orden inferior (una función de la que dependía falló de una manera que no entendió y no pudo planear) lanzar una EXCEPCIÓN ... y si el error ocurrió en la función que está escribiendo actualmente. Bueno, duh, si eres consciente de eso, ¡arréglalo!

Y, finalmente, para responder la pregunta original más directamente: en términos de manejo de ERRORES y EXCEPCIONES, mi consejo sería: manejar todos los ERRORES con gracia (opcionalmente registrándolos) ... pero manejar EXCEPCIONES con cuidado; solo trate de recuperarse de una EXCEPCIÓN si está realmente seguro de que sabe qué es y por qué sucedió; de lo contrario, permita que suba (vuelva a lanzarlo si es necesario).