JavaScript Try/Catch: erros ou exceções?

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

Pergunta

OK. Posso estar dividindo os cabelos aqui, mas meu código não é consistente e gostaria de fazê -lo. Mas antes de fazer, quero ter certeza de que estou indo no caminho certo. Na prática, isso não importa, mas isso está me incomodando há um tempo, então imaginei que perguntaria aos meus colegas ...

Cada vez que eu uso um try... catch Declaração, no bloco de captura, sempre registro uma mensagem no meu console interno. No entanto, minhas mensagens de log não são consistentes. Eles se parecem:

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

ou:

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

Obviamente, o código funciona corretamente de qualquer maneira, mas está começando a me incomodar que às vezes me refiro a "erros" e às vezes para "exceções". Como eu disse, talvez eu esteja dividindo o cabelo, mas que é o apropriado terminologia? "Exceção" ou "erro"?

Foi útil?

Solução

Isso é um pouco subjetivo, mas para mim um erro é quando alguém ou algo faz algo errado, impróprio ou inválido. Pode ser um erro de sintaxe, um erro lógico, um erro de leitura, erro do usuário ou até um erro social. É um conceito abstrato.

Uma exceção, por outro lado, é um objeto que é criado e jogado quando uma certa condição ocorre no código. Pode ou não corresponder a um erro conceitual. Então, para mim, a nomenclatura adequada é "exceção".

Outras dicas

o Especificação Ecmascript os chama de exceções. Você pode querer fazer o mesmo.

Para tornar seu registro mais informativo:

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

Você também pode querer ter em mente que as exceções (infelizmente) podem ser de qualquer tipo, e portanto, não necessariamente name e message propriedades:

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 isso está começando a parecer bastante pesado para repetir em todos os lugares, convém capturá -lo em uma função:

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);
        }
    }
}

Agora você pode dizer:

logExceptions(function() {

    // do some risky stuff...

});

Em JavaScript, é chamado de erro de erro. Então, eu sugiro que você use erros em vez de exceção. Deixe a escolha no meio usando "e". Como nos exemplos de Mozilla.Referência de Javascript 1.5 Mozilla Core

A exceção é algo que você pode esperar, por exemplo, em uma tentativa de abrir um arquivo, pode enfrentar um "arquivo não encontrado exceção". Por outro lado, os erros são algo que você pode não vê -lo vindo como pilha sobre o fluxo ou a memória insuficiente.

Uma exceção é uma saída lógica alternativa de uma função que não produz um resultado lógico. Uma exceção também permite uma melhor explicação do que acontece por que existe dessa maneira. Para a abertura do arquivo, novamente, um identificador de arquivo é um resultado lógico e se o arquivo não existir (uma exceção possível) ou é uma pasta, não um arquivo (outra exceção possível).

Principal de isenção de responsabilidade: Não considero que existe uma resposta "certa" para isso. As opiniões expressas aqui são subjetivas e pessoais. Além disso, as idéias que estou prestes a adotar são úteis apenas se você fizer coisas diferentes com falhas diferentes, ahem ... como você pode usar um sistema de acordo com a resposta informativa de Daniel Earwicker. Com aquilo em mente:

Eu afirmo que "uma exceção é excepcional". Um erro é menos inesperado.

aviso Legal: O seguinte pseudo-código não é bom; apenas serve como o caso mínimo que eu conseguia pensar para ilustrar meu argumento.

Nota: Neste experimento de pensamento, o getfile retorna indefinido se não conseguir encontrar o arquivo 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;
}

No caso de um consumidor chamar GetFileorthRow com um nome de arquivo que não existe, ocorrerá um erro. Na minha opinião, a distinção é realmente que o código de nível superior (ou entrada do usuário) está fazendo algo errado ... Essa função deve transmitir um erro na linha para o código de nível superior que pode decidir o que fazer sobre esse resultado. Considere assim ... essa função estaria dizendo a qualquer função consumida:

Olha, meu amigo, eu sei o que está acontecendo aqui: é um erro solicitar bobaccounts.xml, então não faça de novo! Ah, e se você acha que agora sabe o que poderia ter dado errado (tendo abusado), vá em frente e tente se recuperar!

Agora considere o caso que essa função pega o nome, verifica se o arquivo existe e, por algum motivo, falha em recuperá -lo. Esta é uma situação diferente. Algo realmente inesperado aconteceu. Além do mais, o código consumindo não é o culpado. Agora realmente queremos que essa função diga a quaisquer funções de consumo:

Oh Fiddlesticks! Desculpe por isso, eu humildemente imploro seu perdão, mas algo excepcional que eu realmente não entendo deu errado. Eu não acho que seu pedido de bobaccounts.xml não tenha sido razoável ... e eu sei que deveria estar cumprindo isso para você. Como eu sou um código de nível mais baixo do que você, eu realmente deveria saber o que está acontecendo ... mas eu não ... e como você tem menos chance do que eu de entender essa situação excepcional, acho que você provavelmente seria Melhor parar o que você está fazendo e deixe essa mensagem ir até o topo ... quero dizer, há algo a sério Fishy acontecendo aqui.

Então, suponho que meu resumo seja o seguinte: se o erro aconteceu no código de ordem superior (você foi aprovado por dados ruins), faça um erro. Se o erro aconteceu no código de ordem inferior (uma função de que dependia de falhou de uma maneira que não entendeu e não poderia planejar), faça uma exceção ... e se o erro aconteceu na função, você está escrevendo atualmente .. . Bem, duh, se você estiver ciente disso, conserte -o!

E, finalmente, para responder à pergunta original mais diretamente: em termos de lidar com erros e exceções, meu conselho seria: lidar com todos os erros graciosamente (opcionalmente registrando -os) ... mas lide com exceções cuidadosamente; Apenas tente se recuperar de uma exceção se você tem certeza de que sabe o que é e por que isso aconteceu, caso contrário, deixe -o borbulhar (retirando -o, se for necessário).

O que você recebe em um bloco de captura é uma exceção, então eu o nomei como uma exceção ...

Se for um erro - posso lidar com isso no meu código e geralmente não espero vê -lo no bloco de captura

Hth.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top