Esse bloco abaixo seria para encapsular um método ou algo do tipo? Pois vi em alguma página da apostila da Caleum, mas não estou me recordando muito bem sobre…
throws X {Bloco do X }
Por exemplo, isso esta encapsulando a ação de conectar ao banco.
throws SQLException {
Connection conexao = DriverManager.getConnection("jdbc:mysql://localhost/fj21");
System.out.println("Conectado!");
conexao.close();
}
Será que o que viu não foi isso:
public blaBlaBla() throws Exception{
//faz algo aqui
}
[quote=drsmachado]Será que o que viu não foi isso:
public blaBlaBla() throws Exception{
//faz algo aqui
}
[/quote]
Sim…rsrs. Achei que era desnecessário citar, mas foi isso mesmo.
Neste caso, é uma opção ao tratamento de exceções.
Há três formas de tratar exceções num sistema:
1 - Ignorando-as por completo;
2 - Usando try/catch;
3 - Usando throws;
A primeira não é recomendada, é responsabilidade do desenvolvedor informar ao usuário alguma coisa quando ocorrem erros.
A segunda é mais conhecida, porém, há determinados padrões que indicam que o tratamento de erros deve ocorrer na classe que chama e não na chamada, logo, o try/catch ficaria na principal e, a solução para dizer onde o erro ocorreu é “jogá-lo” para cima.
Esse jogar é feito pela diretiva throws, que é a terceira opção e motivo da tua dúvida.
Quando tentamos converter uma String para Date, podemos receber uma ParseException.
Poderíamos matá-la com um catch(ParseException pe){} ou informar ao usuário que a conversão falhou, jogando a exceção para ele. Isso pode ser feito como abaixo
public Date parseDate(String str) throws ParseException{
SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
return sdf.parse(str);
}
Se ocorrer algum erro, ele será obtido no método que chamou este acima. Claro, como o método acima pode jogar um erro, ao colocarmos a invocação ao mesmo, seremos obrigados a optar por
- jogar novamente a sua exception para cima ou
- tratar com try/catch.
E assim o ciclo segue, até que o usuário seja informado.
Eu acho que não entendi bem a sua dúvida.
O throws serve para lançar uma excessão, não há relação com encapsulamento.
[quote=drsmachado]Neste caso, é uma opção ao tratamento de exceções.
Há três formas de tratar exceções num sistema:
1 - Ignorando-as por completo;
2 - Usando try/catch;
3 - Usando throws;
A primeira não é recomendada, é responsabilidade do desenvolvedor informar ao usuário alguma coisa quando ocorrem erros.
A segunda é mais conhecida, porém, há determinados padrões que indicam que o tratamento de erros deve ocorrer na classe que chama e não na chamada, logo, o try/catch ficaria na principal e, a solução para dizer onde o erro ocorreu é “jogá-lo” para cima.
Esse jogar é feito pela diretiva throws, que é a terceira opção e motivo da tua dúvida.
Quando tentamos converter uma String para Date, podemos receber uma ParseException.
Poderíamos matá-la com um catch(ParseException pe){} ou informar ao usuário que a conversão falhou, jogando a exceção para ele. Isso pode ser feito como abaixo
public Date parseDate(String str) throws ParseException{
SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
return sdf.parse(str);
}
Se ocorrer algum erro, ele será obtido no método que chamou este acima. Claro, como o método acima pode jogar um erro, ao colocarmos a invocação ao mesmo, seremos obrigados a optar por
- jogar novamente a sua exception para cima ou
- tratar com try/catch.
E assim o ciclo segue, até que o usuário seja informado.[/quote]
Em outras palavras o throws serve em determinados casos, como você disse, para mostrar onde ocorreu o erro que com o try/catch poderia ser tratado somente na principal. Eu acho que entendi, se for isso. Obrigado!
Resumindo, com try-catch, o tratamento é imediato e pode gerar “ocultação de cadáver” visto que podemos ter códigos assim
try{
//tenta fazer algo
}catch(Exception e){}
O que causaria, em caso de exception, um problema muito grave.
Já o throws obriga o tratamento, na linha em que o método é chamado, ou que o método onde a chamada existe também possua uma cláusula throws.
Isso garante que, ao menos nesse nível, a exceção lançada não será ignorada. Claro que, como em algum momento teremos o try-catch, o problema anterior pode vir a ocorrer e ocultarmos tudo o que aconteceu.