JavaScript try / catch: errores o excepciones?

StackOverflow https://stackoverflow.com/questions/2587300

Pregunta

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

Cada vez que utilizo una declaración try... catch, en la captura bloquear Siempre registrar un mensaje a mi consola interna. Sin embargo mis mensajes de registro no son consistentes. O bien este aspecto: 

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

o 

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

Es evidente que las funciones de código correctamente en ambos sentidos pero está empezando a molestarme que a veces me refiero a "errores" y, a veces a "excepciones". Como dije, tal vez estoy hilando demasiado fino, pero que es el adecuada terminología? "Excepción", o "error"?

¿Fue útil?

Solución

Esto es un poco subjetiva, pero para mí es un error cuando alguien o algo hace algo malo, 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 se produce cuando una cierta condición se produce en el código. Se puede o no corresponder a un error conceptual. Así que para mí, la nomenclatura adecuada es "excepción".

Otros consejos

El ECMAScript especificación los llama excepciones. Es posible que desee hacer lo mismo.

Para hacer 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 propiedades name y message: 

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 */

A medida que 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...

});

En JavaScript se llama error de captura. Así que le sugiero que utilice error en lugar de la excepción. Dejar la elección en el medio mediante el uso de la "e". Al igual que en los ejemplos de Mozilla. Mozilla Referencia de JavaScript 1.5

Excepción es algo que se puede esperar, por ejemplo, en un intento de abrir un archivo puede enfrentarse a un "archivo no encontrado excepción". Por otra parte, los errores son algo que no se puede ver venir como pila sobre el flujo o no hay suficiente memoria.

Una excepción es una manera lógica alternativa para salir de una función que no produzca un resultado lógico. Una excepción también permite una mejor explicación de lo que sucedería por qué existe esta manera. Para la apertura de archivos, una vez más, un identificador de archivo es el resultado lógico y si el archivo no existe es (una posible excepción) o no es una carpeta de un archivo (otro posible excepción).

MAYOR RESPONSABILIDAD: 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 voy a abrazar sólo son útiles si se va a hacer cosas diferentes con diferentes defectos, ejem, ... como se podría utilizar un sistema según respuesta informativa de Daniel Earwicker. Con esto en mente:

Me sostienen 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 que podía pensar para ilustrar mi punto.

Nota:. en este experimento mental, vuelve GETFILE indefinido 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 realmente tan código de nivel superior (o la entrada del usuario) está haciendo algo mal ... esta función debe pasar un ERROR hasta la línea para que el código de nivel más alto que puede decidir qué hacer con este resultado. Considerarlo como esto ... esta función estaría diciendo a cualquiera de las funciones que consumen:

  

Mira, mi amigo, sé lo que está pasando aquí: es un error a la solicitud BobAccounts.xml, así que no hacerlo de nuevo! Ah, y si cree que ahora sabemos lo que podría haber ido mal (de haber abusado de mí), seguir adelante y tratar de recuperarse de ella!

Ahora consideremos 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. Lo que es más, el código de consumo de no tiene la culpa . Ahora queremos realmente esta función para decir a cualquiera de las funciones que consumen:

  

fiddlesticks Oh! Lo sentimos acerca de esto, humildemente pido perdón, pero algo excepcional que no entienden realmente tiene mal se ha ido. No creo que su solicitud de BobAccounts.xml era razonable ... y sé que debería ser el cumplimiento por usted. Desde que estoy código de nivel bajo de lo que, realmente debe saber lo que está pasando ... pero no lo sé ... y ya que tienes menos posibilidades que yo de entender esta situación excepcional, creo que probablemente mejor simplemente dejar de hacer lo que está haciendo y vamos a este mensaje ir todo el camino hasta la cima ... es decir, hay algo serio gato encerrado.

Así que supongo que mi resumen es el siguiente: si el error ocurrió en una mayor código de pedido (que se aprobaron datos malos) generará un error. Si el error ocurrió en el código de orden inferior (una función que no dependía de una manera que no entiende y no se podía prever) lanzar una excepción ... y si el error ocurrió en la función que está escribiendo actualmente .. . Bueno, duh, si usted es consciente de ello y luego fijarlo!

Y, por último, para responder a la pregunta original de manera más directa: En términos de manejo de errores y excepciones, mi consejo sería: Manejar todos los errores con gracia (opcionalmente registro de ellos) ... pero las excepciones mango con mucho cuidado en verdad; Sólo tratar de recuperarse de una excepción si está realmente seguro de lo que es y por qué ha sucedido, de lo contrario dejar que brotan (Regeneración de que si usted tiene que hacerlo).

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 - que puedo manejarlo en mi código y por lo general no espero verlo en el bloque Catch

HTH.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top