Exceções & Tratamento

O RFW oferece uma estrutura de exceções centralizadas para simplificar o desenvolvimento.

RFWException

RFWException é a classe principal de todas as exceções do sistema, qualquer classe de exceção do sistema deve estende-la. As únicas classes que não farão parte desta hierarquia são as classes de RunTimeException, explicadas mais a frente.

É recomendado que todos os métodos das fachadas da aplicação lancem esta - e apenas esta - classe nos seus métodos. Isso garantirá uma compatibilidade melhor entre versões.

Esta classe é abstrata e não pode ser lançada diretamente. Porém temos uma estrutura de classes herdeiras que devem ser utilizadas conforme a gravidade da exception. De acordo com a classe da exception que for instanciada o Framework dará tratamento diferenciado.

Toda Exceção causa RollBack Note que por padrão, quando utilizado os módulos J2EE, o RFW, através da SMInterceptor, interpreta que qualquer retorno com exceção significa que não foi executado como esperado e força um Rollback. No J2EE, quando queremos que a exception cause o rollback automaticamente, sem a utilização de Interceptors, a Exception deve ter a annotation do EJB: @ApplicationException(rollback = true) Como o módulo RFW.Kernel é proibido de ter dependências externas, nenhuma exception contém esta tag. Se não pretender usar o SMInterceptor mas desejar que a fachada execute o rollback, você terá de utilizar exceptions personalizadas no seu projeto com essa annotation.

Usabilidade

• Os construtores das exception aceitam ao menos 3 argumentos:
  • exceptionCode - Deve ser passado o código da exception. Esse código pode ser utilizado para identificar precisamente um erro do sistema, ajudando tanto equipes de suporte a entender o que está se passando, quanto permitir um tratamento diferenciado em outra parte do software. Além disso esse código é procurado nos arquivos de Bundle para permitir a internacionalização da mensagem de erro para o usuário.
  • params[] - permite passar valores específicos que serão utilizados dentro da mensagem de bundle do erro. Por exemplo, a mensagem do erro é "O valor do campo '${0}' é inválido!", ao passar o valor new String[]{ "Nome" } a mensagem exibida para o usuário será "O valor do campo 'Nome' é inválido!". Verifique o funcionamento das substituições na página do módulo de Bundle: RFWBundle.
  • Throwable - permite fornecer a exception original para que o desenvolvedor tenha a stack completa do problema. Note que este atributo deve ser tratado como obrigatório sempre que houver uma exception antecessora.

Padrão dos Códigos Válidos Para que o RFW interprete que o conteúdo passado é um código e que este deve ser procurado no bundle, ele deve satisfazer a seguinte expressão: "[A-Z0-9_]+". O motivo desse padrão é garantir que o RFW não perderá tempo procurando frases que não sejam chaves válidas para o bundle.

Ignorando o i18n Como alternativa você pode passar a mensagem de erro diretamente neste campo, pois, sempre que o código de erro não for encontrado no bundle o próprio código será utilizado como mensagem. Tenha em mente apenas que ao fazer isso você compromete a internacionalização da aplicação e, sem um código de identificação, impede que a exception seja detectada de forma precisa em outras partes do sistema.

Tipos de SubClasses

RFWCriticalException

RFWCriticalException 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 crí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 RFWCriticalException. Isso porque se o java chegou a enviar alguma exceção que não foi tratada significa uma situação não prevista no código, o que pode gerar BUGs sérios ou mal funcionamento.

RFWWarningException

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.

RFWSecurityException

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.

RFWValidationException

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.

RFWValidationGroupException

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

RFWRunTimeException

Assim como a classe RFWException, 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 RFWException.

Só pense em utilizar exceções do tipo RunTime quando não for possível lançar uma RFWException 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 recomendável) e serão exibidos para o usuário com uma mensagem padrão caso o bundle não esteja disponível.