Criando Exceções

Programação Java
#1

Pessoal,

estou começando a criar minhas exceções agora para poder eliminar um pouco de if dos meus códigos. Exemplo:


 if (!usuario.grava())
 {
  System.out.println(usuario.getMsgErro());
 }

subsituindo por:

 try{
  usuario.grava();
 }catch(Exception e)
 {
   System.out.println(e.getMessage());
   e.PrintStackTrace();
 }

bom, e vi também que poderia estar criando minha própria exceção tipo:

class MinhaExcecao extends Exception
{
  public MinhaExcecao(String msg){
   super(msg);
  }
}

Qual a vantagem em criar minha própria exceção??? Estaria ganhando em que?

Qual a maneira mais indicada de se trabalhar com a criação de exceções?

Obrigado.

#2

A vantagem eh que vc tem exceptions com nomes que facam sentido. Ao inves de vc lancar uma RuntimeException para login invalido, usuario nao encontrato e erro ao gravar a mensagem no banco, vc tem uma InvalidLoginException, UserNotFoundException e DbWriteException. Eh bem mais facil de identificar o problema :slight_smile:

Agora, nao vai ser mto interessante vc trocar os ifs() por um monte de try-catch… o teu codigo vai ficar bem complexo de mexer. Cuidado para nao sair na porra loca :slight_smile:

Rafael

#3

Mas é que tem lugar que eu chego a ter uns 5 if’s aninhados, então queria trocar esses if’s todos por uma instrução do tipo:

try{
  //vários comandos
}catch(FirstException e){...}
catch(SecondException e){...}
catch(ThirdException e){...}

Assim eu poderia saber perfeitamente como proceder em cada exceção e tratar melhor as mensagens pro usuário.

Ou deixa meus if’s mesmo?


boolean resposta = true;

if (!cliente.primeiraAcao())
{
  msgErro = cliente.getMsgErro();
  resposta = false;
}
else
{
 if (!cliente.segundaAcao())
 {
   msgErro = cliente.getMsgErro();
   resposta = false;
  }
  else
  {
    if (!cliente.terceiraAcao())
    {
      msgErro = cliente.getMsgErro();
      resposta = false;
    }
  } 
}

return(resposta);

é mais ou menos isso… horrível, não?

#4

Olá,

Excessões são geralmente para excessões, como por exemplo as que o Rafael citou…

Pelo trecho de código que você passou, isso não me parecem excessões… Mas posso estar enganado…

Por que você não tenta dar return logo depois de cada if? Assim você não precisa ficar encadeando eles…

[]´s

#5

Os métodos retornam false sempre que acontece algo inesperado, como erros nas conexões ao banco. Nesse caso as Exceções caem bem, não?

E, se eu utilizar return o código num vai ficar estilo “go to” não? Tenho medo de com vários return’s ele ficar pior que com os if’s.

#6

É, como os erros são “erros nas conexões ao banco”, como você disse, melhor excessões então…

#7

Neste seu caso me parece bom usar exceções.

Um [ótimo] professor da faculdade dizia. Exceções são legais, MAS cuidado para não transformar seu programa em uma exceção.

#8

Isso tudo é pq estou refatorando o código.

O próximo passo é aplicar algum padrão decente, pq hj meus objetos estão cheios de get’s e set’s e também cada um é responsável por se auto-persistir.

E todos os objetos do sistema (cliente, produto…) utilizam um outro, responsável pelas ações diretas com o banco.

Mas isso é papo para daqui uns dias… vamos dar um passo de cada vez, não?

#9

Na minha opinião, excessão não é uma forma de desvio. Para desvio, existem os ifs e os switchs.

Mas até que funciona.

#10

Olha um caso:

try { contaCorrente.debitar( valor ); } catch( SaldoInsuficienteException e ) { System.out.println("Sem saldo suficiente!"); }

É melhor do que o método retornar false ou qualquer outra coisa, já que o fluxo normal seria debitar e o saldo insuficiente é uma exceção ao fluxo normal.

#11

Sendo assim minhas situações estão dentro do normal!

:wink:

#12

Exceção é uma quebra de contrato, e deveria ser usada assim :wink:

#13

Cara, eh só um comentário inútil, mas estou me lembrando agora de um livro que li em 2002-2003, azulzinho e cujo título em inglês era se não me engano “Java for Idiots”, era muito bom achava a didática muito boa, o mais legal eh que os textos eram bem descontraídos, era um livro engraçado!!

Pena que o conteúdo fosse fraco.

#14