Exceções

Acho que depende…
Mas eu particulamente acho que fica mais claro você tratar logo a exeção.
Você fica repassando só aumenta digitação e a complicação do código.

Pelo contrario. Repassar a exception eh menos codigo. Ao inves de fazer

...
try {
    // codigo
}
catch (AlgumaException e) {
    // tratamento
}
...

vc simplesmnete faz

public void meuMetodo() throws AlgumaException
{
    // codigo
}
...

e trata as exception em um unico try-catch ( no controller, por exemplo ).

Melhor ou pior? ai depende de voce. Eu prefiro a segunda forma, ha tem defenda a primeira.

Rafael

Eu acho que depende muito do caso

só faz sentido passar pra frente se for o escopo do metodo, agora se for algo que é excutado somente internamente e a excessão é de interese somente do metodo é melhor tratar internamente

É claro que essa é a minha opinião, vale a pena esperar e verificar a resposta de pessoas com muito mais experiência do que eu.

Olá

Se for por votaçãO voto com vegeto. Mas pensando bem, em muitos casos meu voto iria para o Rafael. Conclusão: não há regra fixa, cada caso é um caso. E ainda bem que é assim, senão qualquer máquina sairia programando e a gente iria vender pastel na feira.

Programar computadores é uma tarefa completamente subjetiva e ao contrário que a turma de humanas pensa, é bastante criativa. Escolher o caminho a gente faz baseado na experiência com as melhores práticas , na intuição e até no humor do dia (principalmente do chefe). Daí as vezes a gente relê nosso código tempos depois e sente uma vontade danada de melhorar um pouquinho. Isto é uma das piores práticas. Depois que fechamos os testes unitários e integramos nosso código, deve haver um bom motivo para refatorar, nunca só por estética ou elegância.

[]s
Luca

Tratamento de excecoes é SEMPRE um tópico polêmico, e que nao tem uma única resposta precisa e genérica pra acabar com a discussão.

Das que eu li até hoje, a que mais se aproximou disso foi uma frase meio vaga, “trate exceções onde elas devem ser tratadas”. É tão vaga, e responte tão mal a pergunta, que eu me sinto meio que na obrigação de contar um causo.

Seguinte: eu tinha acabado de começar a programar em Java, e, vindo do C++, eu achava checked exceptions as coisas mais chatas do mundo (“ter que ser obrigado a tratar ou lançar uma exception!? QUE SACO!”). Um pouco de tempo depois, começou a fazer sentido: se o erro tem uma probabilidade grande de acontecer, entao pq nao diabos se preparar pra tratar ele? IOExceptions e SQLExceptions sao um caso bem comum aqui.

Se voce esta lendo um arquivo, entao eh bom mesmo vc se preparar pra tomar um erro a qqer momento, pq afinal, fazer um arquivo desaparecer ou acabar antes do que devia é a coisa mais fácil que tem, e nem precisaria ser muito engenhoso pra detonar um sistema desse jeito. Mesma coisa pras SQLExceptions. Se a comunicação com o DB deu pau, entao eh 50% de chance de vc nao conseguir se recuperar, e tem que mostrar o erro pro usuario de algum jeito. Mas e os outros 50%?

É nessa hora que o problema começa. Quando eu estava iniciando em Java, eu simplesmente deixava a exception propagar atéééééé a camada mais rasinha do sistema, e tacava um stack trace na cara do coitado do usuário. Prático, mas nada, nada robusto.

Depois disso, a minha 2a melhor idéia foi “esconder” exceptions. Nada de throws SQLException, quando eu poida encapsular as excecoes em outras, com nomes mais genericos, como ClienteException, e dai sim propagar a coisa pra cima e pra baixo. No final, acabava que TechnicalException encapsula DAOException, que encapsula SQLException. Advinha o que acontecia quando eu tentava entender o que tava escrito em algum stack trace?

A 3a ideia foi parar pra pensar direito onde e quando usar excecoes checadas (“eu posso continuar se acontecer isso?”) e quando usar excecoes nao checadas (“isso NUNCA devia acontecer na execucao normal do programa, e eu nao tenho como me livrar desse erro”). E eh essa que tem funcionado bem ate hoje. Ainda bem, senao era melhor mesmo eu ter ido vender pastel na feira

PS: pensando bem, se eu vendesse pastel na feira eu ia acabar nao conseguindo trabalhar, pq eu ia comer toda a producao. Oops…

O livro Effective Java tem um capítulo inteiro dedicado a exceções.
Os itens 43 e 46 de certa forma abordam essa questão de como tratar a exceção em cada nível.
Se alguém quiser ler meu resumo deste capítulo, está aqui.

O scott meyers nos livros dele de C++ faz um tratado muito bom sobre tratamento de excessões.

O maior problema do java, ao meu ver, é que o modelo de tratamento é incompleto. Voce não tem como escrever um método que simplesmente e dizer pro compilador “esse método não sabe tratar excessões, passe tudo adiante” e ele fazer o trabalho sujo de incluir todas declarações de throws para mim; qualquer ide te faz isso, mas eu não gosto ter 1 página entre a declaração do método e a primeira linha da implementação. Alem disso não existe suporte a uma clausula genérica de catch que não te obrigue a fazer uma gambiarra para propagar a exception.

Se vc tem uma página entre a declaração do método e a primeira linha da implementação, o problema nao sao as exceptions

Eu achei esse artigo interessante que fala sobre checked exceptions e runtime exceptions

um trecho importante que o autor fala

As a rule of thumb, you should always catch a checked exception once you reach a point where your code can make a meaningful attempt at recovery. However, it is best not to catch runtime exceptions. Instead, you should allow runtime exceptions to bubble up to where you can see them.

poucas vezes não tive que repassar exceções. Para mim se algo fora do normal aconteceu o objeto tem avisar.

Vale uma lida:

Rafael

Esse lance de tratamento de exceções é osso viu bacana o artigo da javaworld! Esse lance de repassar excecao é foda quando o escopo disso é muito longo fica um saco pra manipular e tratar essas porra! so mais tratar logo de uma vez!