Esta estrutura serve para encapsular algo?

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.