Dúvidas em Exceções

Acho que depois de toda a complicação que eu arrumei estou começando a entender.

Valeu pela ajuda!

a respeito de sua pergunta.. nesse caso seu a resposta nao.. nao é pq vc declara uma exceção no metodo que ele tem q lançar.. vc declarou dizendo que ali pode ocorrer uma exceção.. e nesse caso de exceções nao-verificadas ela pode ocorrer em todo o seu programa mesmo se declare ou nao.. mais vc nao é obrigado a lançar uma exceção para o metodo que declara...
a declaração diz o seguinte: "olha se o corpo abaixo de {} lançar uma exceção passa a bola para quem me chamou veja"

para tratar colocaria o metodo() do main dentro de :

bom espero ter ajudado, qualquer duvida so gritar

Acho que entendi cara. Mas eu estou complicando muito minha cabeça!

Não sei se foi a maneria como aprendi que foi errada, pois, aprendi que, uma vez que é colocado na assinatura do método o tipo de exceção "throws QualquerException", no corpo do método não é preciso fazer mais nada.

Mas, após alguns códigos que tive que fazer, era necessário colocar "ifs" para lançar a exceção, ou seja, pra que eu usuaria os "ifs" se já estou realizando exceção!?!?! Essa foi minha estúpida dúvida e com a qual estou até agora!

Li as respostas de todos, mas ainda não consegui captar tudo perfeitamente.

Me desculpem pela ignorância, mas quando eu fico com uma coisa confusa na cabeça, é difícil de retirar!

Valeu a todos!

jPscoralicK wrote:Porque, pelo o que eu li, quando você coloca o "throws" na assinatura, não é preciso fazer "mais nada" relativo a exceções dentro do método.

Onde você leu essa besteira?

Colocar throws apenas indica que seu método lança certas exceções. Não tem sentido fazer isso para exceções não-verificadas (como a NullPointerException e o IllegalArgumentException).

Mas, ainda sim, você deve garantir que o código lance as exceções que você indicou, seja de maneira direta (laçando através do throw) ou de maneira indireta (fazendo acesso a um ponteiro nulo, ou chamando um método que gere essa exceção para você).

Mágica e advinhação o java ainda não faz. Mas do jeito que anda, não duvido que fará em alguma versão no futuro...

ViniGodoy wrote:

jPscoralicK wrote:Porque, pelo o que eu li, quando você coloca o "throws" na assinatura, não é preciso fazer "mais nada" relativo a exceções dentro do método.

Onde você leu essa besteira?

Colocar throws apenas indica que seu método lança certas exceções. Não tem sentido fazer isso para exceções não-verificadas (como a NullPointerException e o IllegalArgumentException).

Mas, ainda sim, você deve garantir que o código lance as exceções que você indicou, seja de maneira direta (laçando através do throw) ou de maneira indireta (fazendo acesso a um ponteiro nulo, ou chamando um método que gere essa exceção para você).

Mágica e advinhação o java ainda não faz. Mas do jeito que anda, não duvido que fará em alguma versão no futuro...

Valeu kra! A droga do slide da minha professora tava falando besteira então!

Agora, acho que ela quis te explicar a seguinte situação: imagine que você tem o seguinte método, que insere um nome numa tabela de nomes do banco de dados:

Da forma que está, esse método aí em cima não compila. Por quê? Simplesmente porque os métodos executeQuery e close da classe Statement lançam a exceção verificada SQLException. Veja, o problema aqui é tratar exceções lançadas, e não gerar nossas próprias exceções (como no caso que estava sendo discutido no tópico).

Para isso, temos duas alternativas. A primeira, é colocar um bloco try, catch e realmente tratar a exceção. Algo do tipo:

O tratamento acima é um tanto drástico. Ele loga a exceção em algum arquivo, e depois aborta o programa. No nível em que essa classe está, não teria como fazer um tratamento muito mais sofisticado do que isso. O mais adequado seria partir para outra alternativa.

A outra alternativa, seria deixar para a classe que está usando nosso método tratar a exceção. Nesse caso, não nos preocuparíamos com a SQLException nesse método, mas nas classes que fazem uso desse método. Acho que era essa situação que estava no slide de sua professora.

Fazemos isso com a cláusula throws:

Muito similar ao código original, não? Mas a cláusula throws, na assinatura do método, agora forcará a quem usar o método inserirNome a também usar um try catch, ou continuar lançando a exceção para cima, com outro throws. Embora nesse método não tenhamos mais que nos preocupar com a SQLException (conforme disse sua professora), ainda teremos que nos preocupar com ela no futuro, quando usarmos o método inserirNome.

Agora, nem sempre repassar diretamente a exceção é uma boa idéia. É uma boa prática de programação lançar exceções adequadas a camada que você estiver trabalhando. No caso do exemplo acima, nosso método ficaria:

Parece um mix dos dois, não? Mas, você poderia decidir que FalhaAoInserirNomeException não é uma exceção comum e que, portanto, seria uma RuntimeException. As classes que usam sua classe não precisariam mais captura-la, embora ela ainda ocorresse em caso de problemas e seria logada em algum ponto da aplicação, provavelmente por um UncaughtExceptionHandler.

Qual dos três casos é o mais adequado? Depende. O ideal é que você pare e pense em qual das três alternativas mais se encaixa no momento do tratamento da sua exceção.

Agora, quando o assunto é lançar suas próprias exceções, o throws não vai te ajudar em muita coisa. A não ser ao documentar que sua classe lança essa ou aquela exceção.

Agora uma coisa que você nunca deve fazer é o seguinte código:

Isso aí ignorará todas as exceções, sejam elas runtime ou não. Uma péssima idéia. Seu código poderá executar algo inválido e continuará prosseguindo, simplesmente imprimindo o erro, mas ignorando que ele ocorreu. Isso certamente gerará problemas maiores.

Na pior das hipóteses, faça:

Pelo menos assim, você deixa de se preocupar com a exceção, mas não deixa de lança-la, ainda que sem a necessidade de captura-la. Quando possível, parta para uma das três primeiras alternativas.

E note que, de novo, colocamos como parâmetro da RuntimeException a exceção original. Novamente para indicar a causa. Isso é muito importante no log que será gerado, especialmente se o problema ocorrer em campo.

Grande ViniGodoy! Agora sim cara, finalmente, depois de toda minha burrice saquei tudo! Valeu mesmo kra!

Viva o GUJ! \o/

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