Como sobrescrever um método que não lança exceção e fazer ele lançar exceção? [RESOLVIDO]

This message was edited 2 times. Last update was at 30/12/2010 15:02:13

Pessoal, boa tarde!

Gostaria de saber se há alguma técnica para contornar o seguinte problema:

Quero estender a classe DefaultTreeModel e sobrescrever o método abaixo:

Só que gostaria de fazer algumas verificações antes de permitir que seja inserido um nó na árvore (JTree). Caso algum critério não seja cumprido, queria disparar uma exceção (que iria para os níveis superiores até chegar ao usuário), impedindo assim que o nó (nosso TreeNode) fosse adicionado à árvore.

Ou seja.. após herdar a classe, fazer isso:

Têm alguma técnica que posso usar para contornar esse problema e poder lançar a exceção para cima? Técnica para adicionar lançamento de exceções em método herdado que originalmente não tinha (mantendo a herança dele) ?

Grato

GUJ Master Membro desde: 29/05/2008 14:09:28 Mensagens: 1617 Online

Sim, basta que sua exceção estenda java.lang.RuntimeException ao invés de estender java.lang.Exception diretamente. Assim o compilador não exigirá que sua exceção seja declarada na assinatura do método.

Ok, vou testar e informo se obter sucesso!

Valeu! Achava que esse problema era insolúvel ...

This message was edited 1 time. Last update was at 28/12/2010 17:26:47

Você pode lançar uma RuntimeException (que não é uma checked exception) que encapsula outra exceção.

Exemplo:

Vc precisa de uma classe que É UMA DefaultTreeModel?

Vc poderia usar composição ao inves de herança e ter uma classe X que TEM UM atributo que é uma DefaultTreeModel e vc adiciona / remove nesse cara e a sua classe se preocupa em validar de acordo com as suas regras.

Inclusive sua classe X poderia implementar a interface TreeModel para ser mais compativel com algumas coisas. Lançar RuntimeException quando vc quer validar de forma explicita se algo deu certo me parece um tanto errado.

Vejo outra opção: pense em criar a sua classe de forma imutavel e o insertBlaBlaBla retorna uma nova instancia da sua classe com estas alterações e um método isValid para verificar se o objeto é bacana ou não.

This message was edited 3 times. Last update was at 29/12/2010 08:02:18

peczenyj wrote:
Vc poderia usar composição ao inves de herança e ter uma classe X que TEM UM atributo que é uma DefaultTreeModel e vc adiciona / remove nesse cara e a sua classe se preocupa em validar de acordo com as suas regras.

Sim, poderia. Mas não poderia usar como filho do DefaultTreeModel. Teria que adaptar todas as classes para lidar com essa.

peczenyj wrote:
Inclusive sua classe X poderia implementar a interface TreeModel para ser mais compativel com algumas coisas. Lançar RuntimeException quando vc quer validar de forma explicita se algo deu certo me parece um tanto errado.

Sem dúvida. Mas como vou lidar só com String's, me parece um esforço desnecessário implementar um TreeModel personalizado só para lançar uma exceção se uma condição não for satisfeita...
Outra abordagem seria a que você apresentou acima. Que daí seria o mais "correto".

peczenyj wrote:
Vejo outra opção: pense em criar a sua classe de forma imutavel e o insertBlaBlaBla retorna uma nova instancia da sua classe com estas alterações e um método isValid para verificar se o objeto é bacana ou não.

Aí eu quebro o mecanismo de herança. Não quebro? O método é void:

Acho que uma alternativa melhor é criar uma interface com o método isValid. Daí eu checaria se o model implementa a interface e se o método isValid retorna true. Caso não retorne, eu já saberia que houve duplicação...

Resumindo: Acho o problema simples demais e insignificante para maiores preocupações. Será usado em alguns trechos do programa (3 trechos). Só é para checar se há elementos repetidos no modelo. Se houver, disparar uma exceção. A abordagem do Runtime parece interessante porque somente onde for interessante checar a duplicação e onde eu souber que estou usando o DefaultTreeModel herdado é que vou manipular essa exceção.

This message was edited 1 time. Last update was at 29/12/2010 08:07:42

marcobiscaro2112 wrote:Você pode lançar uma RuntimeException (que não é uma checked exception) que encapsula outra exceção.

Exemplo:
public void teste() { // não há declaração de throws try { // algum código que pode lançar uma IOException } catch (IOException e) { throw new RuntimeException(e); } }

Hoje de manhã vou testar e aviso. A idéia é essa mesma. Lançar "para cima" essa exceção, para ser manipulada nos métodos superiores da pilha, até chegar na interface gráfica (na classe do JFrame, que irá tratar a exceção).

A propósito, se você for usar a abordagem de encapsular a exceção, crie uma classe filha de RuntimeException, que você usará no seu catch. Exemplo:

No hora de tratar a exceção, faça um catch só para a sua exceção criada.

Isso é importante pois há pelo menos umas 50 subclasses diferentes de RuntimeException só na API padrão e capturar tudo isso em um catch fica muito genérico.

This message was edited 1 time. Last update was at 29/12/2010 10:44:44

A abordagem está funcionando. Estou conseguindo capturar a exceção em nível superior.

A propósito, se você for usar a abordagem de encapsular a exceção, crie uma classe filha de RuntimeException

Estou fazendo isso agora. É melhor mesmo, para evitar capturar outra RuntimeException...

Só um detalhe. De que adianta seu TreeModel lançar uma exceção, se seu JTree não está preparado para captura essa mesma exceção?
Se o método não tem esse tipo de coisa no seu contrato, de nada adianta disparar a exception.

This message was edited 1 time. Last update was at 30/12/2010 14:59:32

ViniGodoy wrote:Só um detalhe. De que adianta seu TreeModel lançar uma exceção, se seu JTree não está preparado para captura essa mesma exceção?
Se o método não tem esse tipo de coisa no seu contrato, de nada adianta disparar a exception.

A idéia é simples. É para capturar a exceção do TreeModel, mas não será o JTree que irá capturar.

As funções CRUD da JTree serão feitas por JButtons e JPopMenu. São nos ActionListeners dos botões e opções do JPopMenu é que vou capturar as exceções do TreeModel. Só vou usar a JTree para obter a instância do TreeModel. Esta instância será justamente uma instância da minha classe herdada da DefaultTreeModel, que encapsula a exceção dentro de uma RuntimeException.
Eu manipulo a instância do TreeModel e verifico se houve a exceção. Se tiver ocorrido, informo o usuário e desfaço as alterações no TreeModel (ou posso impedir de serem salvas).

This message was edited 2 times. Last update was at 30/12/2010 15:00:37

Deu certo.

Minha aplicação, na interface gráfica, verifica se houve uma "ExceptionContainer" (a extensão que fiz da classe RuntimeException) e trata a exceção contida dentro dela (a que eu lanço da TreeModel, nos níveis mais inferiores, ao inserir e alterar nodos da árvore).
Essa exceção sobe as camadas, sem declarações de throws, sendo capturada só onde interessa e sem eu precisar criar um TreeModel do zero...

Notícias, artigos e o maior fórum brasileiro sobre Java