raise: quando usar e quando n�o usar

Question

as vezes eu uso um bloco try... except, e a�, depois de tratado o erro,eu mostro uma mensagem customizada por mim e talvez ainda concatene com a mensagem do exception. Tipo assim:[code:1:f50f45a701]tr...

Tnaires · Answer

Ol�Tudo isso depende do comportamento do seu m�todo. Acredito que a maneira mais elegante seja colocar um raise Exception.Create(�Msg�) dentro dos m�todos, e �proteg�-los� com try / except no ambiente de execu��o. Exemplo:[code:1:104062b2f7]procedure MeuMetodo;begin  if CoisaRuim then    raise Exception.Create(�Coisa ruim.�);end;procedure AmbienteExecucaoMeuMetodo;begin  try    MeuMetodo;  except    Application.MessageBox(PChar(E.Message), �Erro�, MB_OK + MB_ICONERROR);  end;end;[/code:1:104062b2f7]Inclusive, um tratamento gen�rico de exce��es pode ser escrito para o evento OnException do Application, ou utilizando um AppEvents. Mas e se voc� tiver alguma fun��o que precise retornar algo, independendo das condi��es de erro? Nesse caso, o try / except vai pra dentro da fun��o. O bloco except atribui ao Result um valor v�lido, mas que simbolize erro dentro do contexto do programa ( -1, por exemplo ).Abra�os...

Michael · Answer

Em geral � prefer�vel usar exce��es para notificar erros, do que valores de retorno. Exce��es s�o auto-descritivas - ou pelo menos deveriam ser - , podem carregar mais informa��es sobre o problema e garantem que caso um erro ocorra ele dever� ser tratado, pois caso contr�rio o aplicativo abortar� (em Java, por exemplo, o compilador obriga vc a tratar qualquer m�todo que levante uma exce��o, usando try..catch). Veja um exemplo:

TConection = class
public
  function Connect: Boolean;
end;

...
begin
  Connection.Connect;
  Connection.ExecQuery(...);
  ...
end;

Se a conex�o falhar, vai ocorrer outro erro na linha abaixo pq eu n�o tratei o retorno do m�todo. Se uma exce��o fosse levantada de dentro de [b:c1efa33f78]Connect[/b:c1efa33f78], nada ap�s seria executado.

Outro ponto: se vc utilizar valores de retorno em cada m�todo, vai precisar usar um tipo mais flexivel do que [b:c1efa33f78]Boolean[/b:c1efa33f78], pq dificilmente a quantidade de erros pass�veis de ocorrem ser� bin�ria. E n�o � recomend�vel �agrupar� erros em um �nico significado, pois isso dificulta a localiza��o do ponto exato do problema. Usando ainda o m�todo [b:c1efa33f78]Connect [/b:c1efa33f78]da classe mostrada acima como exemplo, se ele retornar [b:c1efa33f78]False[/b:c1efa33f78], como ser� poss�vel saber se o problema � pq a senha do usu�rio est� incorreta, pq o banco informado n�o existe, ou pq simplesmente a rede est� offline?

Nessas situa��es, costuma-se usar [b:c1efa33f78]Integer [/b:c1efa33f78]como tipos de retorno. Por�m, em paralelo, vc vai ter que montar tabelas de c�digos de erro, para poder saber o que um 1, 2 ou -1 significam. Isso n�o � bom, e tende a tornar a manuten��o do c�digo mais trabalhosa, pois o significado de cada c�digo n�o ser� o mesmo em todos os m�todos: 1 � uma coisa para o m�todo Foo1, e outra para o m�todo Foo2, etc.

Por estas e outras raz�es que eu recomendo utilizar exce��es para notificar erros na aplica��o.

[]�s

Vitor Rubio · Answer

Valeu pelas respostas, pessoal!O meu caso � o seguinte: antes eu tratava a excess�o dentro do m�todoe retornava, para quem o chamou, true ou false, para saber se houve erro ou n�o. Mas a exception era gravada num log e, as vezes, tambem era mostrada para o usuario num messagebox. S� que agora � diferente....agora a minha classe n�o vai mais ser usada diretamente pela interface, mas vai ser �encapsulada� por um m�todo de uma outra classe. N�o sei se eu trato a exception da mesma maneira e se retornar false eu �reraiso� essa exception, ou se eu simplesmente mostro messagebox ou se eu deixo todo o tratamento na interface. Desse jeito eu nunca vou saber que erro que ocoreu, � verdade. Mas se eu deixar pra tratar tudo na interface, vou ter muitos c�digos parcialmente repetidos para tratamento dessas excess�es. N�o sei uma outra forma de saber, mostrar e logar, na parte mais externa, o que aconteceu de errado na parte mais interna....

Tnaires · Answer

N�o daria certo voc� escrever uma rotina gen�rica de tratamento de exce��es e atribu�-la ao evento OnException do Application, ou mesmo a um AppEvents?

Dessa forma, voc� trata as exce��es em um canto s�, sem repeti��o de c�digo, e sem usar Application.MessageBox em classes que n�o deveriam tratar de janelas e interfaces com o usu�rio.

Vitor Rubio · Answer

o problema � o seguinte:
minhas classes instanciam objetos de outras classes, em varios niveis.

se ocorrer uma exces�o num m�todo e eu tratar e mostrar um messagebox, beleza, depois disso o metodo continua.

Mas se eu propagar a mensagem de erro j� tratada, com uma mensagem minha, criando oexception, tipo raise exception.create(�minha mensagem de erro�) a aplica��o trava a�, e n�o prossegue.

eu preciso que a aplica��o prossiga, para poder dar um free nos objetos instanciados.

veja o exemplo:

procedure TForm1.Button1Click(Sender: TObject);
var objeto : TStringList;
begin
  objeto := TStringList.Create;
  raise Exception.Create(�teste�);
  ShowMessage(�testou?�);
  objeto.Free;
end;

o objeto n�o vai ser liberado nunca, e isso ocorre em varios lugares. Alem disso, eu tenho log de erro por e-mail, por arquivo texto e por banco de dados...

Tnaires · Answer

Para liberar os objetos, use [b:c9ec1ef0b9]finally[/b:c9ec1ef0b9].

Exemplo: suponha que voc� tem um m�todo particular que gere uma exce��o:

TClasse = class
  public
    procedure MeuMetodo;
  end;

procedure TClasse.MeuMetodo;
begin
  raise Exception.Create(�Exce��o criada.�);
end;

A rotina gen�rica de erro pode tratar essa exce��o, e grav�-la no log sem problemas, pois ela recebe uma refer�ncia � pr�pria exce��o como par�metro ( vide evento OnException do componente AppEvents ). Para resolver o problema de libera��o de objetos, fa�a:

with TClasse.Create do
  try
    MeuMetodo;
  finally
    Free;
  end;

Nesse caso, o objeto sempre ser� liberado ap�s a execu��o do m�todo, independente de haver exce��o ou n�o.

Vitor Rubio · Answer

Mas considere o c�digo que voc� mesmo criou:

TClasse = class 
  public 
    procedure MeuMetodo; 
  end; 

procedure TClasse.MeuMetodo; 
var AlgumaCoisa: ToutraClasse;
begin 
  AlgumaCoisa := ToutraClasse.create;
  AlgumaCoisa.FazOQueTemQueFazer;
  If CoisaRuimAconteceu then
    raise Exception.Create(�Exce��o criada.�); 
  AlgumaCoisa.Free; //nunca vai entrar nessa linha  
end;

with TClasse.Create do 
  try 
    MeuMetodo; 
  finally 
    Free; //n�o adianta dar free aqui, porque o objeto "AlgumaCoisa" n�o vai ser liberado
  end;

Eu uso exceptions para, alem de mostrar as mensagens de algo ruim para o usuario, criar um log, mas eu n�o posso criar exceptions para coisas boas, esse � um problema. Outro problema � o seguinte: se eu criar uma fun��o assim:

procedure RaiseOrShow(msg: string; Reraise: Boolean = True);
begin
  if  Reraise then
    raise Exception.Create(msg)
  else
    MessageBox(0, PChar(msg), �Erro!� , ADV_ALERTA);
end;

eu queria saber se � correto, quando for mensagem boa fazer:

raisorshow(�mesnagem de sucesso�, false);

e quando for ruim fazer:

RaiseOrShow(�iih, Ferr�!�, true);

d� certo? o raise para no lugar certo? onde ele dever� ser tratado?

Tnaires · Answer

Beleza.No contra-exemplo que voc� citou, um finally viria a calhar:[code:1:1abbc24944]TClasse = class  public    procedure MeuMetodo;  end;procedure TClasse.MeuMetodo;var AlgumaCoisa: ToutraClasse;begin  AlgumaCoisa := ToutraClasse.create;  try    AlgumaCoisa.FazOQueTemQueFazer;    If CoisaRuimAconteceu then      raise Exception.Create(�Exce��o criada.�);  finally    AlgumaCoisa.Free; //Essa linha sempre ser� executada  end;end;[/code:1:1abbc24944]A regra �: try/finally sempre deve ser usado quando um objeto que executa um m�todo pass�vel de exce��o precisar ser liberado imediatamente ap�s sua execu��o.Sobre o RaiseOrShow, eu afirmo o seguinte: exceptions s� devem ser utilizadas quando houver algum erro cr�tico no sistema, que possa comprometer sua execu��o. Para avisos, informa��es gerais, �mensagens boas� e etc, n�o use exce��es. Seguindo essa afirma��o, o RaiseOnShow perde todo o sentido....

Vitor Rubio · Answer

Era isso que eu precisava saber! Eu n�o sabia que voc� podia colocar
try.. finally numa exception que voc� mesmo �raisou�

quanto ao RaiseOrShow, � que eu queria usar a mesma maneira de mostrar uma mensagem, idependente de acontecer coisa ruim ou boa, ent�o o raiseorshow mostraria mensagem caso acontecesse coisa boa ou geraria exception no caso de coisa ruim.

tipo assim:

RaiseorShow(mensagem, (a=b));

mas eh meio estranho, n�?

Vitor Rubio · Answer

tnaires, olha s� esse teste que eu fiz:[code:1:af7cf894b8]procedure TForm1.Button1Click(Sender: TObject);var objeto : TStringList;begin  try    objeto := TStringList.Create;    Exit;    raise Exception.Create(�teste�);  finally    ShowMessage(�testou?�);    ShowMessage(�testou mesmo�);    objeto.Free;  end;end;[/code:1:af7cf894b8]O finally executa mesmo depois de um exit!!! :D:D:D:De eu n�o sabia disso! Era tudo o que eu queria. Muito obrigado, voc� me ajudou muito!!!...

Tnaires · Answer

Beleza, qualquer coisa estamos a�!...

Vitor Rubio · Answer

apareceu outra duvida sobre exceptions:eu estou usando  o raise para propagar exceptions caousadas dentro de classes minhas para serem tratadas na interface com o usuario.as vezes as exceptions n�o s�o geradas pelos meus objetos, mas sim por objetos usados por eles.Ent�o no exemplo:[code:1:aa14c57e50]try  MeuObjetoQueMandaEmail.Envia; //se der exception aqui, provavelmente � senha invalida ou coisa do tipo, e foi o idSmtp que gerou.except  {a minha duvida � aqui: eu uso raise exception.create(�deu erro�) ou s� raise?}  raise;end;[/code:1:aa14c57e50]queria saber quando usar raise; e quando usar raise exception.create(�bla bla bla�), e tambem quando usar o:[code:1:aa14c57e50]on e: exception dobegin  raise ou raise exception;  cuida da coisa ruim;end;[/code:1:aa14c57e50]...

Vitor Rubio · Answer

Outra coisa: Se as exceptions s�o objetos da classe Exception, quem � que da free nelas?...

Tnaires · Answer

O raise isolado dentro de uma cl�usula exception serve para repassar a inst�ncia da exce��o.

try
  try
    raise Exception.Create(�Coisa ruim�);
  except
    on E: Exception do
    begin
      // Faz alguma coisa e repassa a exce��o
      raise;
    end;
  end;
except
  on E: Exception do
  begin
    // Trata a exce��o repassada
  end;
end;

O bloco try/except externo vai receber a exce��o repassada.

Por falar em on E: Exception... Esse comando serve para tratar um tipo ( classe ) de exce��o espec�fico. Exemplo:

type
  ECoisaRuim = class(Exception);

  ECoisaPiorAinda = class(Exception);

...

procedure MeuMetodo;
begin
  try
    // Este m�todo pode gerar ECoisaRuim ou ECoisaPiorAinda
    GerarException;
  except
    on E1: ECoisaRuim do
    begin
      // Tratamento para exce��es do tipo ECoisaRuim
    end;
    on E1: ECoisaPiorAinda do
    begin
      // Tratamento para exce��es do tipo ECoisaPiorAinda
    end;
  end;
end;

[quote:6031bfc017=�vitor^_^�]Outra coisa: Se as exceptions s�o objetos da classe Exception, quem � que da free nelas?[/quote:6031bfc017]

Diretamente do help do delphi:

When an exception handler actually handles the exception, it finishes by destroying the exception instance, so you never need to do that yourself.

:wink:

Vitor Rubio · Answer

Legal, eu n�o sabia que as exceptions no delphi tinham tanto poder de fogo assim. Estou programando errado a alguns ANOS.

e no caso do on e: exception do eu posso simplesmente usar para mudar a mensagem da exception antes de repassar ela pra frente, por exemplo:

  try 
    MetodoQuePodeGerarException;
  except 
    on E: Exception do 
    begin 
      // Faz alguma coisa e repassa a exce��o 
      //Metodos que tratam o erro se necess�rio
      raise exception.create(�Minha mensagem personalisada com a original concatenada no final� + #1310+ e.message); 
     //o resto vai seer tratado depois, na classe que chamou esse metodo
    end; 
  end;

Valew pela ajuda!

F�rum raise: quando usar e quando n�o usar #330609