Erros comuns no tratamento de exceções

Uma exceção é uma interrupção no fluxo normal de execução de um programa Java (ou qualquer outro). Esta violação pode ocorrer devido a uma violação de acesso à memória, divisão por zero, problema de inicialização, execução de uma instrução ilegal ou qualquer outro erro fatal. Java é capaz de lidar com todos esses cenários indesejados com elegância, mas quando se trata de usar esses recursos Java pelos desenvolvedores, vários problemas podem surgir. Neste artigo, não vou discutir como funciona o tratamento de exceções em Java. Presumo que o leitor já esteja familiarizado com a hierarquia de exceções, exceções verificadas , exceções não verificadas e exceções de tempo de execução . Aqui discutiremos os erros mais comuns que você deve evitar.

Partes interessadas nas exceções

Sempre que o thread de execução for interrompido, as informações sobre ele deverão ser devolvidas ao executor do programa. Este thread pode começar na tela, em uma tarefa em lote ou de qualquer outra forma. Todos esses gatilhos aguardam algum tipo de violação no fluxo para transmitir uma mensagem de determinado formato. Um gatilho baseado em tela pode nos informar que há alguns problemas técnicos e que devemos entrar em contato com o suporte para obter ajuda e aconselhamento. Processos em lote ou programas Java autônomos podem esperar que o relatório de erros apareça na forma de algum tipo de log que é completamente incompreensível para o usuário final. Mas os empresários precisam receber mensagens numa linguagem que compreendam. A temida NullPointerException na mente dos usuários é muito irritante. Às vezes esses erros são consequência do uso incorreto do programa, mas às vezes são problemas que requerem correção. A segunda parte interessada importante é a pessoa que terá de lidar com os problemas levantados pelas excepções. Essa pessoa não pode observar a execução real do programa quando ocorre a exceção. Ele se baseará em duas coisas: primeiro, informações fornecidas pelo usuário que está tendo o problema e, segundo, algum tipo de log gerado quando ocorre uma exceção. Além disso, a pessoa que irá analisar o problema não é a mesma que escreveu o programa e, portanto, o desenvolvedor do programa deve fornecer informações suficientes para a análise. A única forma de comunicação entre o desenvolvedor do programa e seu depurador é um log. Além disso, às vezes, por motivos de segurança, o log às vezes pode não conter todos os detalhes reais da execução do programa quando a exceção ocorreu. Vejamos possíveis erros no tratamento de exceções. Alguns deles parecem muito estúpidos, mas existem pessoas. que não prestam atenção a eles até que esses erros levem a problemas.

Bloco de exceção vazio

Este é um dos erros mais indesejados no tratamento de exceções. Neste caso, a exceção é simplesmente ignorada. A solução contém apenas uma linha de comentários para deixar a exceção. try{ }catch(SQLException sqe){ // do nothing } Em alguns casos raros, como no bloco final quando o banco de dados é encerrado, exceções podem ser lançadas. Neste caso eles podem ser ignorados. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Generalização incorreta da mensagem de exceção

Este ponto é subjetivo. Depois de capturar a exceção, você pode reportá-la ao usuário final na forma de uma mensagem amigável. É bem possível que os detalhes da mensagem original sejam perdidos quando as mensagens originais forem convertidas em uma mensagem geral. A mensagem deve transmitir as informações adequadas ao usuário final para que, ao entrar em contato com a equipe de suporte, o usuário só precise fazer login no log apropriado para fornecer as informações. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } Em um aplicativo multicamadas, cada camada captura exceções e lança um novo tipo de exceção. Às vezes é absolutamente necessário lançar uma exceção de um determinado tipo: - Camada de Acesso a Dados -> cria uma DataAccessException - Camada de Implementação de Negócios -> cria uma BusinessException - Camada de Serviço de Aplicação -> cria uma ApplicationServiceException Tudo parece lógico, não é? Aqui podemos ter que escolher entre ApplicationServiceException e BusinessException, pois ambos podem representar a mesma informação. Uma dessas conversões de exceção parece desnecessária.

Destruindo a classe StackTrace

Durante o processo de transformação de uma exceção em um novo tipo especial, o rastreamento de pilha pode desaparecer, tornando um pesadelo rastrear a causa real da exceção. No código abaixo você pode ver como uma nova exceção é lançada sem receber nenhuma informação da exceção original. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Substituindo o motivo da exceção

Cada mensagem de exceção contém informações sobre o motivo da exceção. No entanto, quando uma nova exceção é criada, as informações sobre a antiga podem ser excluídas permanentemente. Isso é semelhante ao exemplo acima, onde o StackTrace pode ser removido devido ao lançamento de uma nova exceção.

Não há busca por exceções específicas

Às vezes, os desenvolvedores gostam de jogar pelo seguro ao lidar com exceções. Às vezes isso é fácil de fazer. Mas capturar java.lang.Exception em vez de uma exceção específica não é aceitável. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Pegar e jogar desnecessário

Capture exceções se desejar convertê-las para outro tipo ou se isso ajudar a adicionar algumas informações à mensagem de exceção para o usuário final ou analista. Caso contrário, apenas jogue-os fora na assinatura do método (usando lançamentos) em vez de capturá-los.

Capturando RuntimeException

Eu recomendaria evitar capturar RuntimeException. Em vez disso, é melhor capturar exceções específicas e tratá-las.

Encontrando exceções não verificadas

É um tópico controverso capturar exceções não verificadas ou não. NullPointerException e ArrayIndexOutOfBound podem ser os melhores exemplos de exceções não verificadas. Em vez de capturar essas exceções, você pode alterar seu código para lidar com esses cenários. Por exemplo, para evitar NullPointerException, para garantir que todas as variáveis ​​sejam inicializadas, para evitar exceções ArrayIndexOutOfBound, para definir uma matriz com o comprimento correto, etc.

Problemas relacionados ao log de exceções

A revista ajudará o segundo interessado, ou seja, quem analisa o problema. Às vezes, um desenvolvedor exagera nos arquivos de log e os logs são criados em todos os níveis do aplicativo. O log deve registrar a exceção no nível em que ocorreu. Parece ideal exibir um aviso de que ocorreu uma exceção, com uma proposta para parar ou continuar a execução do programa e registrar obrigatoriamente a exceção no log.

Exceção de controle de fluxo

Uma exceção é uma interrupção no fluxo normal do programa, o que significa que você precisa interromper esse fluxo e informar o usuário final sobre isso. Se adicionarmos uma chamada de método que seja um thread alternativo, isso causará enormes problemas de manutenção. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Uso onipresente de java.lang.Exception

Também não é uma boa ideia usar java.lang.Exception em todos os lugares para qualquer exceção. Em vez disso, é melhor usar exceções específicas do aplicativo ou as exceções Java padrão mais apropriadas. Artigo original: Erros comuns no tratamento de exceções Traduzido e dublado por: Ve4niY