Try catch - boas práticas

eu penso assim:

se vc tem uma classe que cuida de alguma coisa, e quer perdir pra outra classe gravar algo, logo vc não quer se preocupar em exceção, nem nada… do tipo:

try { dao.inserir("alguma coisa"); } catch (AlgumaException e) {}

no meu entendimento, a classe q efetivamente vai manipular a leitura, gravação é que precisaria tratar os erros.

é isso q vc quer saber?

mas acho q qnto a isso, nao há uma opção certa ou errada, é questao de como vc ve as coisas, projeta e acha que fica melhor

Grato pela atenção,

Na realidade a dúvida é sobre onde usar o try/catch. Por exemplo, se deveria fazer tudo separado:

try { conn = Driver.getConnection(strConn) } catch (SQLException) { ... }
try { stmt = conn.createStatment() } catch (SQLException) { ... }
try { rs = stmt.executeQuery(sql) } catch (SQLException) { ... }
try { while (rs.next() {...} } catch (SQLException) { ... }
try { conn.close() } catch (SQLException) { ... }

ou se devo fazer tudo junto

try { 
  conn = Driver.getConnection(strConn);
  stmt = conn.createStatment();
  rs = stmt.executeQuery(sql);
  while (rs.next() {...} 
 conn.close() 
} catch (SQLException) { ... }

ou se deveria criar um classe para manipular tudo, tratando os exceptions, por exemplo:

class MySQL() {
  public ResultSet query() {
    try { ... } catch () { ... }
  }

  public Connection connect() {
    try { ... } catch () { ... }
  }

  public void close() {
    try { ... } catch () { ... }
  }
}

gostaria de saber qual a meneira correta, mais elegante e prática de se tratar exceptions quando há possibilidade de receber vários deles. Como venho do VB6, não tenho muito essa noção.

grato.

Acho que depende um tanto... Eu considero as Exceptions uma boa alternativa na hora de propagar a mensagem de erro 'pra cima', em direção a tela.
Por exemplo, você manda inserir um registro no banco. Ele vai da tela, faz algumas validações (basicamente ver se faltam campos obrigatórios e coisas desse tipo) e passa para o lado interessante da coisa. Lá, você vai fazer os tratamentos e tchururu. Se ocorrer uma Exception, usa o try catch pra tratar e tranquilo. Só que dentro do catch, depois de tratar, você poderia dar um throw new XException ou coisa do tipo, pra que as camadas 'mais de cima' possam tratar isso (nunca testei isso, essa ideia me veio na cabeça agora, então não sei se dá certo).

Não tenho nem ideia se isso é uma boa prática... É meio estranho porque você teria que tratar os erros 2 vezes, mas é uma boa alternativa pra pegar as mensagens quando chegar na tela (e não apresentar um "Impossível cadastrar registro no banco de dados." ou "Erro.").

public class FrontEnd {
	
	public static void main(String[] args) {
		try {
			new BackEnd().fazerTalCoisa();
		} catch (Exception e) {
			System.err.println("Opa, deu crap.");
			System.err.println(e.getMessage());
			e.printStackTrace();
		}
	}

}

public class BackEnd {

	public void fazerTalCoisa() throws Exception {
		try {
		} catch (Exception e) {
			// Tratar o erro aqui (fazer um rollback, por exemplo)
			throw new Exception("Mensagem que pode aparecer na tela.");
		}
		
	}

}

Não testei, então não sei dizer se funciona.

[Editado]
Sobre essa sua outra dúvida, eu acho que depende bastante. Você pode generalizar quando só quer ver a stacktrace e ser mais específico quando existem diversos tipos de erros (pra apresentar nas telas, por exemplo).

eu gosto de fazer +- assim como o André Brito disse, apenas complementando, para obter a conexão com o banco de dados seria legal você ter uma classe para isso, que o pessoal normalmente chama de ConnectionFactory, que retorna a mesma conexão, um exemplo disso seria uma classe com o seguinte conteudo:

private static Connection conn;

public static Connection getConnection(){

  if (conn == null || conn.isClosed()) criaConexao();

  return conn;
}

essa classe garantirá que você vai usar sempre a mesma conexão, evitando assim que você crie varias conexões onde em certos casos isso pode te trazer problemas... em certos casos você ainda pode ter uma fila de conexões, cria um poll, etc, vai da sua necessidade, ou até curiosidade, com o tempo você vai ver que é bem melhor você usar frameworks ORM como o Hibernate para isso por exemplo...