Exceptions

Eu li o artigo: Effective Java Exceptions(link) no Dev2Dev. Leiam pois o artigo é muito bom.

Nesse artigo ele fala sobre dois tipos de execptions as falhas e as contingências.
As falhas são coisas irecuperaveis, como acabou a memória ou o banco de dados está fora do ar, para esses casos se utiliza uma uncked exception, ou sejá, uma Runtime exception. Contingências são exceptions que nos podemos tratar e continuar um fluxo de execução por isso o correto de uma contingência é ele ser checked, ou seja, herdar de Exception ou alguma outra exceção checada.

Mas se você pega uma exeção checada(contingencia) e simplismente ecapsula ela em uma runtime exception ou usa throws para ir levantando até a ponto, isso está errado pois se ela é uma contingecia deve ser tratada, agora se é uma falha deveria ser runtime exceptio.



Um ati-pattern que podemos ver muito por ai é retornar null ou -1 para sinalizar um erro, a arquitetura de exceptions do java existe justamente por conta disso, fazer isso é errado. Fiz testes de benchamrks sobre isso levantando 1.000.000 de runtime exceptions contra 1.000.000 de retornos null em uma camada e a diferença foi menos de 3s, nada justiica fazer isso como poucas camadas. E devemos pensar, cara isso é java não C++.

Outro conceito interresante é o Exception Barrier que podemos encontrar no Spring MVC e no Struts por exemplo.Quando usamos runtime exceptions deixamos o código mais limpo e diminuimos a sua complexidade, fazendo o fluxo ser mais natuaral, então em uma camada acima tera uma sessão de contingecia aonde essas exceptions do tipo runtime serão tratadas, acredito que essa sejá umas das melhores abordagens e mais coesa a nivel de arquitetura.

Por hoje é isso, falou pessoal.
Se não gostaram, por diabo com vocês.

Popular posts from this blog

Telemetry and Microservices part2

Installing and Running ntop 2 on Amazon Linux OS

Fun with Apache Kafka