Exceções & Tratamento: mudanças entre as edições

De BIS Wiki
Ir para navegação Ir para pesquisar
Criou página com 'O framework BIS oferece um serviço para simplificar o tratamento das exceções do sistema centralizado. Esse serviço tem em mente que tratar é registrar e documentar os di...'
 
 
(2 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 1: Linha 1:
O framework BIS oferece um serviço para simplificar o tratamento das exceções do sistema centralizado. Esse serviço tem em mente que tratar é registrar e documentar os diferentes tipos de exceções que ocorrem e em casos críticos enviar notificações para a equipe de desenvolvimento.
O BIS oferece exceções do sistema centralizado para simplificar o desenvolvimento.
 
Para diferenciar os tipos de tratamentos o serviço disponibiliza alguns tipos de exceções, cada uma receberá um tipo de tratamento diferenciado.


== BISException ==
== BISException ==
Linha 8: Linha 6:
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.
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 gra vidade.
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.
 
{{stop|Toda Exceção é RollBack|Note que por padrão o BISFW interpreta que qualquer método que lance uma exceção foi um método que não executou como esperado. Assim, caso um método de fachada lance uma BISException o BIS e seus Interceptors admitem que tivemos um problema e por isso a necessidade de fazer um RollBack.
 
Assim, a classe BISException tem a annotation do EJB:
<pre>@ApplicationException(rollback = true)</pre>
Que indica que o interceptor ou qualquer fachada cuja transação seja controlada pelo container deve executar o RollBack.
}}


=== BISCriticalException ===
=== BISCriticalException ===
Linha 20: Linha 25:
{{nota|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.}}
{{nota|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.}}


==== BISTransactionException ====
Filha de BISCriticalException, é lançada quando ocorrer algum erro de transação, como se ao tentar manipular um banco de dados não houver uma transação válida. Normalmente o desenvolvedor não necessitará lançar esta exceção pois toda a transação já é provida e tratada pelo framework.
==== BISCloneNotSupportedException ====
Filha de BISCriticalException, é lançada quando não for possível clonar um objeto do BIS. (Normalmente VOs).
==== BISUnsuportedFeatureException ====
Filha de BISCriticalException, é lançada sempre que for solicitado alguma função que ainda não está pronta no BIS ou foi esquecida de ser implementada. Por exemplo: em uma cadeia de IFs ou Switch para verificar o valor de uma variável, e se chega no caso 'else' indicando que para aquele valor de variável nada foi implementado. Lançando esta exceção no caso 'else' dessas situações facilita o mapeamento de futuros erros, caso contrário o método poderia retornar um valor inválido e explodir o funcionamento em outro local.


=== BISWarningException ===
=== BISWarningException ===
Linha 42: Linha 35:
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.
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.


==== BISDatabaseException ====
Lançada quando ocorrer um erro de acesso ao banco de dados. Tomar cuidado para não mascarar neste warning alguma exceção de gramática SQL (o que deve ser um erro crítico).
==== BISReportException ====
Lançada quando ocorrer um erro criando o relatório.
==== BISLookupException ====
Lançado quando não for possível realizar o looukp por um JNDI desejado.


==== BISValidationException ====
=== 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.
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.
Linha 71: Linha 53:


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.
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.
== Exibição das Exceções ==
As exceções são classificadas por nomes e ícones, que ajudam o usuário (e o próprio desenvolvedor) a entender a gravidade da ocorrência. Para saber como exibir as mensagens para o usuário e padrões visuais verifique a documentação da UI.

Edição atual tal como às 18h14min de 12 de outubro de 2020

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.

Toda Exceção é RollBack
Note que por padrão o BISFW interpreta que qualquer método que lance uma exceção foi um método que não executou como esperado. Assim, caso um método de fachada lance uma BISException o BIS e seus Interceptors admitem que tivemos um problema e por isso a necessidade de fazer um RollBack.

Assim, a classe BISException tem a annotation do EJB: 

@ApplicationException(rollback = true)

Que indica que o interceptor ou qualquer fachada cuja transação seja controlada pelo container deve executar o RollBack.

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.


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.

Disponível em “http://wiki.biserp.com.br/index.php?title=Exceções_%26_Tratamento&oldid=1055”