Exceções & Tratamento

De BIS Wiki
Ir para navegação Ir para pesquisar

O BIS oferece exceções do sistema centralizado para simplificar o desenvolvimento.

BISException

BISException é a classe principal de todas as exceções padrões do sistema, isto é, qualquer classe de exceção do sistema deve ser uma classe filha desta (diretamente ou indiretamente). As únicas classes que não farão parte desta hierarquia são as classes de RunTimeException, explicadas mais a frente.

Entre diversas vantagens de centralizar os códigos comuns das exceções, também simplifica o lançamentos nas interfaces. É padrão no BIS lançar sempre a classe pai, o "throws BISException" nos métodos. Isso garantirá uma compatibilidade melhor entre versões.

Esta classe é abstrata e não pode ser lançada diretamente. Já as diferentes classes filhas tem funções específicas e seus tratamentos são diferenciados. Por padrão o tratamento de uma classe de exceção qualquer é apenas registrado tal como uma exceção de validação, no entanto algumas das classes filhas tem um tratamento completamente diferenciado baseado na sua gravidade.

BISCriticalException

BISCriticalException deve ser usado para emitir um erro crítico. Erro crítico é aquele erro que jamais deveria ter acontecido! É aquela exceção geralmente causada por erro de lógica, como todos os NullPointerException e como a maioria dos RunTimeException (por não terem sido capturados e/ou tratados adequadamente). Esta exceção é tratada como um BUG no sistema.

Esta exceção é reportada para a equipe de desenvolvimento. Por tanto, valide e trate os erros de ambiente para evitar o lançamento de exceções cíticas em erros simples como:

  • Erro ao acessar o banco de dados porque o mesmo estava desligado.
  • Erro ao acessar um WS por problemas da internet.


Note 64.png
Exceções nativas são erros críticos
Por não saber diferenciar a gravidade das exceções nativas do Java, toda exceção nativa, seja Exception ou RunTime, será tratada como uma BISCríticalException. Isso porque se o java chegou a enviar alguma exceção que não foi verificada e tratada significa uma situação não prevista no código, o que pode gerar BUGs sérios ou mal funcionamento.


BISWarningException

Esta classe representa um erro ao realizar o processamento. Não é um erro crítico, que represente uma falha de implementação, mas algo como falha de acesso, erro ao acessar o banco de dados (por estar desligado, não por erros de gramática SQL), erro ao acessar um WS por indisponibilidade de rede, etc. Não é uma mera validação dos dados entrados, mas sim uma indisponibilidade do ambiente que não permitiu que o processamento fosse realizado. Este tipo de exceção é enviado para o desenvolvimento automaticamente, embora não seja um erro crítico (que impossibilite o funcionamento do sistema) o acontecimento frequente de Warnings pode ser considerado um erro do sistema.

BISSecurityException

Estas exceções devem ser lançadas sempre que alguma operação for solicitada por por alguém sem acesso. Permitindo que a tentativa de acesso seja registrada.


BISValidationException

Exceção de validação é lançada sempre que algum pré-requisito de operação chamada não estiver completo. Por exemplo, chamar um método para inserir um cadastro e o campo obrigatório não foi preenchido, ou não tinha o tamanho adequado, etc. Cada validação do pré-requisito que falhou gera uma exceção de validação.

BISValidationGroupException

Esta classe também é lançável como uma exceção e tem valor equivalente ao BISValidationException, a vantagem desta classe é que ela suporta uma coleção de BISValidationException. Assim, ao validar seus pré-requisitos uma determinada operação pode acusar mais de uma falha ao mesmo tempo.

BISRunTimeException

Assim como a classe BISException, esta classe deve ser a classe pai para todas as exceções do tipo RunTime. E não devem ser usadas quando for possível usar alguma classe da hierarquia de BISException.

Só pense em utilizar exceções do tipo RunTime quando não for possível lançar uma BISException comum. Como por exemplo ao implementar interfaces de outros componentes em que não se pode lançar nenhuma outra exceção.

As exceções desse tipo são sempre tratadas como um erro crítico e serão reportadas à equipe de desenvolvimento.

Esses erros não são obrigados a ter um código de erro (embora fortemente recomendável) e serão exibidos para o usuário com uma mensagem padrão caso o bundle não esteja disponível.