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

Programação – Item 55

Online_video_marketing_optimize_conversion_rates_tips_id35618561Otimize Criteriosamente

A historia das décadas passadas nos mostram que otimização prematura na verdade é mais propenso a causar danos do que benefícios. O caminho da otimização precoce pode leva-lo a uma solução que ainda não seja rápida, arquiteturalmente ruim e pior de tudo inflexível de difícil evolução. Portanto, não tente criar programas rápidos! Na verdade, foque em criar bons programas, usando todos os conceitos, princípios e abordagem necessários. Se um programa bem arquiteturado não for rápido suficiente, a boa arquitetura já estabelecida permitira que ele seja facilmente otimizado. Não pense em problemas de desempenho enquanto estiver projetando uma solução. Quando terminar a codificação, avalie seu desempenho. Se ele for suficientemente rápido, tudo estará resolvido. Caso contrário, localize a fonte de gargalo usando uma ferramenta de gerador de perfil e trabalhe nas partes relevantes. Repita esse processo conforme necessário, avaliando o desempenho após cada alteração até apresentar um tempo satisfatório.

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

“Tudo quanto, pois, quereis que os homens vos façam, assim fazei-o vós também a eles; porque esta é a Lei e os Profetas.” Mateus 7:12