[quote=maior_abandonado]pessoalmente eu acho que não é legal mesmo você usar exceção “como se fosse um if”, mas em certos casos eu ainda acho que fica melhor… esse provavelmente é um destes. Considero melhor por que com a exceção, primeiro que o código fica mais fácil de ler, bater o olho e entender ele, segundo pro que ele ficará mais rápido na maioria dos casos, pense bem, na maioria dos casos espera-se este campo não esteja nulo, sendo assim ao invés de ficar fazendo um monte de comparação já o pega direto e o usa.
mesmo nos casos onde estiver nulo, la por exemplo nos últimos itens, precisaria do teste más desconfio que o lançamento da exceção seja mais rápido que a verificação a partir da terceira, sei la…
um ultimo comentário, se isso for utilizado em mais lugares, a lei de demeter torna-se mais interessante, então isso ficaria no endereço…
sei que isso vai contra certos princípios de códigos bem escritos, mas acho que me baseei nos motivos destes princípios (legibilidade de código, se usada a lei de demeter reaproveitamento e quando for importante, performance).
claro que isso é opinião, se eu estiver errado em algum ponto aceito criticas construtivas.[/quote]
Existe um ranking de práticas, ou seja, algumas são melhores que outras. Então tempos, más práticas, práticas, boas práticas e melhores práticas.
As melhores práticas dizem que vc não deve usar try-catch para tratar nullpointer. A razão disso não é legibilidade, é que pode mascarar outros defeitos que não aquele que vc acha que vai acontecer e ai seu programa vai começar a funcionar errado, mas parecendo que funciona certo. No exemplo em estudo, se o endereço em si for null temos a mesma execeção. Mas se o endereço em si for null o erro está em outra parte do sistema que não está lendo ele direito. Mas o que vc vai ver é nenhum erro e nenhum odigo IBGE nunca. Isto é um bug mais complicado de avaliar, e pela simples razão que fez catch de nullpointer.
Existem razões lógicas e até matemáticas por baixo das melhores práticas. Não é apenas um agregado de ideias avulsas. A legibilidade também é um boa prática, mas neste caso o que vc chama de “legebilidade” signiica “escrever menos”. Escrever menos não é uma boa prática em si mesmo e não é razão que justifique coisa alguma. Legibilidade é “eu entendo o que leio”. O programador que ler o catch não vai entender porque o nullpointer está sendo capturado sem um coment que explique. Portanto, não está ajudando à legibilidade coisa nenhuma.
É comum este sentimento de “posso violar as melhores práticas se houver um boa razão” e isso é verdade, o problema é que as razões que são dadas são normalmente más.
A lei de demeter é sempre importante , como todos os principios em geral. dizer que existe uma ocasião quando ela não é importante é como dizer que às vezes a gravidade não atrai os objetos.
Vejam assim, estes princípios são forças internas ao design OO e elas operam , ou deveriam operar, para chegar num melhor modelo. Mas tem as forças externas que também operam sobre o sistema e impedem o modelo de ser o melhor que poderia. Estas forças externas são várias como custo e tempo mas temos também a indulgência do programador em achar que a sua razão é boa o suficiente para contrariar os princípios. E este é o real problema. Porque é de certa forma subjetivo e artificial. ( ou contrario do custo e do tempo que são reais ).
Então, a menos que a gente goste de apostar o design dos sistema na nossa indulgência é melhor não violar os principios. É para isso que eles foram reunidos.
