Arquivos de Categoria: Java Effective

Exceções – Item 65

dontignoremeNão ignore as exceções

Um bloco catch vazio invalida os fundamentos e a finalidade das exceções (checadas e não checadas) que é forçar a manipulação de condições excepcionais. Caso você tenha alguma situação no qual realmente não faça sentido fazer nenhuma implementação coerente em um tratamento de exceção, use uma das abordagens:

  • Comentário de código – nó mínimo escreva um comentário dentro do catch explicando o porquê foi apropriado não fazer nada com aquela condição de exceção.
  • Log – registre os ocorridos em um recurso de log apropriado.

Para todas as informações, veja o post inicial.

“Grande paz têm os que amam a tua lei; para eles não há tropeço. Salmos 119:165

Exceções – Item 64

bombanuclear_hypesciencepontocomBusque atomicidade das falhas

Após um objeto lançar uma exceção, é desejável que ele continue em um estado bem definido e usável. Resumidamente, uma chamada de método incorreta deve deixar um objeto no estado que ele estava antes da chamada. Existem algumas abordagens para obter esse efeito:

  • Usar objetos imutáveis (Item 15) – se uma operação falhar, um novo objeto imutável não será criado e consequentemente não deixara o antigo em um estado inconsistente.
  • No uso de objetos mutáveis – verifique e valide todos os parâmetros antes de execução da operação (Item 38), fazendo a exceção ser lançada antes de qualquer alteração interna.
  • Código de recuperação – criar um código que armazene e reverta seu estado ao ponto anterior de inicio da operação.
  • Cópia temporária – criação de cópia temporária do objeto a ser processado e a substituição do conteúdo do objeto pela cópia, uma vez que a operação tiver sido concluída com sucesso.

A busca dessa atomicidade nem sempre é desejável, uma vez que para alcançar essa característica você pode aumentar significativamente o custo, complexidade de sua solução e até ocasionar perda de performance na solução.

Como regra sempre busque usar a atomicidade. Onde esse regra não for aplicável, a documentação da API (Item 44) deve indicar claramente em que estado o objeto poderá ser deixado.

Para todas as informações, veja o post inicial.

“Tornai-vos, pois, praticantes da palavra e não somente ouvintes, enganando-vos a vós mesmos.” Tiago 1:22

Exceções – Item 63

os-pequenos-detalhes-sao-sempre-os-maisInclua informações de captura de falha em mensagens de detalhe

Quando um programa falha devida a uma exceção não checada, a JVM automaticamente exibe o rastreamento de pilha de execução com a descrição texto da determinada exceção. Estas costumam serem as únicas informações que os programadores ou o pessoal de serviço de campo têm quanto investigam uma falha no software. Portanto, é criticamente importante que o método toString() da exceção retorne o máximo possível de informações com relação a causa da falha.

Diante disso, é altamente recomendável que a mensagem de detalhe de uma exceção contenha os valores de todos os parâmetros e campos que contribuíram para gerar a falha do sistema. A abordagem que garante essa prática é assegurar que os construtores das determinadas exceções recebam como parâmetros os valores necessários para construir uma mensagem que ocasionaram a condição de exceção.

Para todas as informações, veja o post inicial.

“Ditoso o homem que se compadece e empresta; ele defenderá a sua causa em juízo.” Salmos 112:5

Exceções – Item 62

jmx-javadocDocumente todas as exceções lançadas por cada método

Uma descrição das exceções lançadas por um método é parte importante da documentação requerida para uso apropriado do método. Portanto, é criticamente importante que você documente cuidadosamente todas as exceções lançadas em cada método que você criar. Isso deve ser feito para exceções checadas e não checadas, para métodos concretos e abstratos. Se você não documentar toda as exceções, será difícil ou impossível para outras pessoas fazerem uso efetivo de suas classes e interfaces.

Para todas as informações, veja o post inicial

“Pois não me envergonho do evangelho, porque é o poder de Deus para a salvação de todo aquele que crê, primeiro do judeu e também do grego.” Romanos 1:16

Exceções – Item 61

do it - procrastination conceptLance exceções apropriadas à abstração

Existem alguns problemas quando uma API lança uma exceção referente à invocação de uma camada de nível inferior:

  • A exceção repassada não tem conexão aparente com a tarefa requisitada a ser executada do ponto de vista da camada invocadora.
  • Exposição detalhes de implementação interna da camada em uso.
  • Poluição da camada invocadora referente aos detalhes de implementação interno da camada em uso.
  • Inflexibilidade na manutenção. Quando detalhes internos de uma camada forem alteradas, resultara em impacto em todas as suas camadas invocadoras.

Portanto, as camadas superiores devem encapsular totalmente os detalhes e situação excepcionais internos, utilizando uma das seguintes abordagens:

  1. Encadeamento de exceções – definir e lançar exceções coerentes com o nível de abstração oferecida, encapsulando os detalhamentos internos. Use o encadeamento de exceções oferecido pela classe Exception.
  2. Contorno Silencioso – tratar as situações excepcionais internos transparentemente para as camadas invocadoras, registrando os ocorridos em um recurso de log apropriado.

Para todas as informações, veja o post inicial

“Pois a nossa pátria está nos céus, de onde também aguardamos o Salvador, o Senhor Jesus Cristo.” Filipenses 3:20

Exceções – Item 60

exceptions - elephantPrefira o uso de exceções padrão

As bibliotecas padrão do Java fornecem um conjunto básico de exceções não checadas que abordam grande parte da parcela das necessidades de lançamentos de exceções da maioria das API’s. O seu reuso torna a criação de sua API mais fácil de aprender, ler, diminui o numero de classes, gastando menos memória no carregamento. Diante disso, prefira sempre reutilizar estas exceções não checadas existentes antes de criar as suas. As mais comuns são:

  • IllegalArgumentException
  • IllegalStateException
  • NullPointException
  • ConcurrentModificationException
  • UnsupportedOperationException
  • NumberFormatException

Somente reuse algumas dessas se a condição em questão realmente for condizente com as suas respectivas documentações de uso. Caso contrário, você fica livre para especifica-las (herança) a ou até criar suas proprietárias.

Para todas as informações, veja o post inicial

“Certamente, a palavra da cruz é loucura para os que se perdem, mas para nós, que somos salvos, poder de Deus.” 1 Coríntios 1:18

Exceções – Item 59

avoidEvite o uso desnecessário de exceções checadas

O uso excessivo de exceções checadas pode tornar a utilização de uma API desagradável, impondo uma carga adicional de trabalho sobre o programador usuário. Sendo assim, evite o uso de exceções checadas a menos que a condição excepcional possa realmente ser recuperada, confrontando o programador a fazer alguma coisa de útil quando tratar a condição. No resto, prefira usar exceções não checadas ou a abordagem que transforma uma exceção checada em dois métodos separados, um retornando um booleano indicando o acontecimento do caso excepcional e outro que execute e operação.

Para todas as informações, veja o post inicial

“Sabemos que todas as coisas cooperam para o bem daqueles que amam a Deus, daqueles que são chamados segundo o seu propósito.” Romanos 8:28

Exceções – Item 58

2153Use cada tipo de exceção corretamente

A linguagem Java fornece três tipos diferentes de criação de exceções, cada uma para um fim específico:

  1. Checadas – usadas para situações em que o chamador tenha condições de se recuperar.
  2. Não Checadas – usadas para indicar erros de programação.
  3. Erros – usadas exclusivamente pela JVM para indicar deficiências em recursos e falhas em invariantes que tornem impossível continuar a execução da solução.

Sendo assim, use as exceções “Checadas” caso julgar que a condição é recuperável, senão use exceções de “Não Checadas” para definir erros de programação. Não crie nenhuma exceção do tipo “Erros”, uma vez que elas são por convenção reservadas exclusivamente para condições de erros da JVM.

Para todas as informações, veja o post inicial

“O caminho de Deus é perfeito; a palavra do SENHOR é provada; ele é escudo para todos os que nele se refugiam.” Salmos 18:30

Exceções – Item 57

consolidated-dont-do-it-deck-7875-p2326-5324_zoomSó use exceções em condições excepcionais

As exceções foram projetadas para fazer sinalização de condições excepcionais. Portanto, não use exceções para controle de fluxo e não crie API que forcem os outros a usarem com controle de fluxo.

Para todas as informações, veja o post inicial.

“A resposta branda desvia o furor, mas a palavra dura suscita a ira.” Provérbios 15:1

Programação – Item 56

txtAdote convenções de nomeação geralmente aceitas

A plataforma Java tem um conjunto bem estabelecido de convenções de nomeação para criação dos elementos de programação: pacotes, classes, interfaces, anotações, tipos genéricos, métodos, campos e variáveis. Raramente esses padrões devem ser violados e nunca sem uma boa razão. Segue as consequências de violar essas convenções:

  1. API fica difícil de ser utilizada.
  2. API fica difícil de ser alterada.
  3. Confundir e irritar os programadores usuário da API.
  4. Podem causar suposições falsas resultando em erros.

Diante disso, aprenda as convenções de nomeação padrão da plataforma Java e use com bom senso. Segue o link do Java Code Convention.

Para todas as informações, veja o post inicial.

“Filhinhos, não amemos de palavra nem de boca, mas em ação e em verdade.” 1 João 3:18

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 556 outros seguidores