Try/cath ou throws?

Try / catch

Você cria um código dentro do try, qualquer exceção que der, ele vai tratar ela no catch…

Por exemplo:

public class Divisao {
    int numero, divisor;
    double resultado;    

    Try {
        numero = 10;
        divisor = 0;
        resultado = numero / divisor;
    } catch (Exception e) {
       e.printStackTrace;
    }

Neste caso, quando der a exceção alguma coisa dividido por zero ele vai dar a exceção e vai executar o que está dentro do catch…

Já no caso do throws, é para você jogar uma exception… por exemplo:

...
resultado = null;
if (resultado == null) {
   throw new NullPointerException("Resultado é nulo");
}

Ai na sua classe você tem que ter um catch que trata essa excesão ou então ela vai explodir na tela escrito: “Resultado é nulo”

Entendeu?
Galera, me avisem se estiver errado, pois ainda sou um pouco novato…

Complementando…
Se a própria classe consegue tratar o problema de forma transparente a quem estará usando, use try/catch
Senão, use throws para que a classe que receber a exceção faça o que achar necessário no contexto dela.

Você também pode usar ambos, por exemplo tratando alguma parte da exceção dentro do cacth e ainda no final dele lançar a mesma exceção (ou outra mais apropriada) para quem chamou o método.

Ok pessoal entendi !

Mas e quando vc usa o throws em metodos por exemplo:

public void fazAlgo() throws IOException {}

o que acontence na verdade ?

ate hoje eu nao consegui tratar nada por try/catch de forma inteligente sem ser na camada de apresentacao…

alguem tem ai um exemplo “do mundo real” aonde é possivel tratar um erro internamente???

Tentar conectar novamente de 30 em 30 segundos caso o banco de dados esteja fora do ar

“maxguzenski”:

alguem tem ai um exemplo “do mundo real” aonde é possivel tratar um erro internamente???

Normalmente exceptions checadas é muito dificil de recuperar 100%, afinal, esse é o pq de ser checadas.

Um exemplo é quando estiver lendo um arquivo .properties e ocorrer uma IOException, pode-se voltar aos valores padrões e procurar por um outro arquivo válido.

Outro caso muito comum é com JDBC, tive recentemente por sinal: tratar quando o cache tem registros inválidos (que já tinham sido removidos no banco), para isso voce tem que extrair da SQLException essa informação, um porre btw.

Isso se deve a vicios de programacao. Por exemplo, se voce vai fazer um metodo para realizar uma media, um calculo estatistico, que haja uma divisao, eh muito comum, na maioria das linguagens , realizar um IF antes para ver se nao vai tentar dividir por zero, e se for zero, devolver, sei la, um -1 como resposta

Ja com tecnicas mais avancadas, de tratamento de excessoes, eh perfeitamente possivel voce colocar direto um return com adivisao e colocar entre ele um try/catch por DivideByZeroException, tipo, e nesse catch retornar o -1. Voce troca o if por try/catch.

Claro que isso eh um exemplo simples, mas voce pode aplicar esse tipo de pensamento para outros lugares, por exemplo, num metodo para ler o conteudo de um arquivo, ao inves de ficar dando if para ver se o arquivo existe, se da para ler (permissao), vai e tenta abrir o dito cujo. Se nao conseguir abrir, voce cata isso num IOException e realiza a devida acao, que seria retornar uma string vazio por exemplo.

Agora realmente se o fato do arquivo nao existir eh um erro de instalacao, talvez seja interessante criar um ErroDeInstalacaoException e lanca-la, atraves de throw e a camada de apresentacao dar o erro correto.

“tiagogn”:

Mas e quando vc usa o throws em metodos por exemplo:

public void fazAlgo() throws IOException {}

o que acontence na verdade ?

Na prática, não acontece nada. A única coisa é que quando você chamar o método fazAlgo você vai ter que colocar essa chamada dentro do bloco try ou fazer o método também propagar essa exceção. Ou seja, ela obriga que quem chamar esse método esteja preparado para lidar com a possibilidade de receber essa exceção. Mas só via lançar a exceção mesmo se você der o throw no corpo do método (ou se ela já estiver sendo propagada por alguma chamada que acontece lá dentro).

Boa leitura sobre isso:
http://java.sun.com/docs/books/jls/second_edition/html/exceptions.doc.html#44044