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.
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.
