Artigo Clube Delphi Edição 8 - Tratando Erros com Exceções Parte I – Manipulando Exceções

Atenção: por essa edição ser muito antiga não há arquivo PDF para download. Os artigos dessa edição estão disponíveis somente através do formato HTML. 

Tratando Erros com Exceções Parte I – Manipulando Exceções

Quando um erro ocorre em seu aplicativo, durante a execução, a aplicação chama uma exceção. Uma exceção é um objeto que contém informações sobre o erro ocorrido e onde ele ocorreu. Se você não especificar em seu código uma resposta ao erro, o Delphi mostrará uma mensagem descrevendo o erro.

O ideal seria que você pudesse tratar os erros ocorridos, evitando a perda de dados ou a necessidade de encerrar a aplicação. Além de tratar o erro a rotina de tratamento de erros poderia enviar ao usuário uma mensagem em português, mais significativa.

Obs: Quando você está no ambiente do Delphi, executa a aplicação e ocorre um erro, o Delphi lhe mostra uma mensagem de erro própria (independente da que você cria para manipular o erro). Você deve fechar esta caixa de mensagem e clicar um Run, para que a execução da aplicação continue. Só neste momento será mostrada a mensagem criada por você para manipular o erro. Quando você executa a aplicação fora do ambiente do Delphi, só a caixa de mensagem criada por você é mostrada.

Mensagem criada pelo usuário

O Delphi permite que você desenvolva aplicações robustas, ou seja, que tratam os erros ocorridos de forma que os dados não se percam. Para fazer uma aplicação robusta, é necessário que o código reconheça exceções quando elas ocorram, respondendo a elas.

Blocos Protegidos

Você cria uma resposta a uma exceção em um bloco de código, chamado de bloco protegido porque está resguardado de erros que podem parar a aplicação ou perder dados. Um bloco protegido começa com a palavra reservada try e termina com a palavra reservada end. Entre estas palavras você determina os comandos protegidos e a forma de reação a erros.

Quando você define um bloco protegido, especifica respostas a exceções que podem ocorrer dentro deste bloco. Se a exceção ocorrer, o fluxo do programa pula para a resposta definida, e após executá-la, abandona a bloco.

A forma mais simples para responder a uma exceção é garantir que algum código limpo é executado. Este tipo de resposta não corrige o erro, mas garante que sua aplicação não termine de forma instável. Normalmente, usamos este tipo de resposta para garantir a liberação de recursos alocados, mesmo que ocorra um erro. Para isto, usamos a estrutura try...finally...end.

Outra forma de se responder a uma exceção é tratando o erro, ou seja, oferecendo uma resposta específica para  um erro específico. Ao tratar o erro destruímos a exceção, permitindo que sua aplicação continue a rodar. Para isto, usamos a estrutura try...except...end.

A Estrutura Try...Finally..End

Seu código precisa garantir que, mesmo ocorrendo um erro, os recursos alocados sejam desalocados. Entre estes recursos estão: arquivos, memória, recursos do Windows, objetos.

Para garantir a desalocação dos recursos, usamos a estrutura abaixo:

{aloca os recursos}

try

{códigos que usam recursos}

finaly

{libera os recursos}

end;

A aplicação sempre executará os comandos inseridos na parte finally do bloco, mesmo que uma exceção ocorra. Quando um erro ocorre no bloco protegido, o programa pula para a parte finally, chamada de código limpo, que é executado. Mesmo que não ocorra um erro, estes comandos são executados.

Exemplo

A aplicação a seguir possui uma caixa de edição e um botão:

Ao entrarmos com o valor 0 na caixa de edição, e clicarmos no botão Calcular, geramos um erro, ao tentarmos dividir 10 por 0. Apesar do erro, o programa libera a memória alocada:

procedure Tform1.

Button1Click(Sender:Tobject);

var

   Apointer: Pointer;

   a, b: Integer;

begin

   a:=StrtoInt(Edit1.Text);

   GetMem(Apointer, 1024);

try

   b:=(10 div a);

   Edit1.Text:=IntToStr(b);

finally

   FreeMem(Apointer, 1024);

end;

end;

Exceções da RTL

Quando você escreve código que chama rotinas da biblioteca de run-time (RTL, run-time library), como funções matemáticas ou de manipulação de arquivos, os erros aparecem na forma de exceções. Por padrão, a RTL manda uma mensagem para o usuário, mas você pode tratar estes erros de outra forma.

As exceções geradas pela RTL são definidas na unit SysUtils, e todas descendem da classe Exception, que provê a string que aparece no quadro de mensagem da exceção.

Há diversos tipos de exceções geradas pela RTL, como por exemplo:

n exceções de entrada e saída;

n exceções de memória heap;

n exceções matemática envolvendo inteiros;

n exceções matemáticas envolvendo pontos flutuantes;

n exceções de typecast;

n exceções de conversão;

n exceções de hardware.

Você pode observar estas exceções com mais detalhes através do Object Browser, ativado através do comando View|Browser:

Exceções de Entrada e Saída

Ocorrem quando a RTL tenta acessar arquivos ou dispositivos de entrada e saída.

A unit SysUtils define uma exceção genérica de entrada e saída chamada EinOutError, que contém um atributo chamado ErrorCode que indica o erro ocorrido.

Exceções de Memória Heap

Ocorrem quando você tenta alocar ou acessar memória dinâmica. São definidos dois tipos de exceções: EoutOfMemory (indica que não há memória suficiente), e EinvalidPointer (ponteiro inválido).

Exceções Matemáticas para Inteiros

Ocorrem quando você realiza operações com números inteiros. A unit SysUtils define uma exceção genérica chamada EintError, com três tipos de exceções derivadas: EdividByZero (divisão por zero), ErangeError (número ou expressão fora da região), e EintOverflow (estouro na operação com inteiro).

Exceções de Pontos Flutuantes

Ocorrem quando são feitas operações com dados do tipo real. A unit SysUtils define uma exceção genérica chamada EmathError, com as seguintes exceções derivadas: EinvalidOp (procesador encontrou uma instrução indefinida), EzeroDivide (divisão por zero), Eoverflow, Eunderflow.

Exceções de Typecast

Ocorrem quando você tenta atribuir um objeto a um tipo inválido usando o operador as. Gera-se a exceção EinvalidCast quando isto ocorre.

Exceções de Conversão

Ocorrem quando se convertem dados de tipo para outro. A unit SysUtils define uma exceção chamada EconvertError quando isto ocorre, avisando que a conversão não pode ser feita.

Exceções de Hardware

Podem ocorrer em dois tipos de situação: quando o processador detecta uma falha, ou quando a aplicação gera uma interrupção intencional

Entre as exceções de hardware geradas temos: EaccessViolation (acesso ilegal de memória), EstackedOverflow (acesso ilegal ao seguimento stack do processador).

A Estrutura Try..Except..End

Um tratamento de exceção é um código que trata erros que ocorrem dentro de blocos protegidos.

Para definir um tratamento de exceção, utilize a seguinte construção:

try

{comandos que você deseja proteger}

except

{comandos de tratamento}

end;

A aplicação irá executar os comandos na parte except somente se ocorrer um erro. Se na parte try você chamar uma rotina que não trata erros, e um erro ocorrer, ao voltar para este bloco a parte except será executada. Uma vez que a aplicação localiza um tratamento para a exceção ocorrida, os comandos são executados, e o objeto exceção é destruído. A execução continua até o fim do bloco.

Dentro da parte except definimos um código a ser executado para manipular tipos específicos de exceção:

try

{comandos que você deseja proteger}

except

on Exceção do {código a ser executado de acordo com a exceção gerada}

end;

A palavra reservada on define respostas para uma exceção. On está sempre junto de do, para manipular a exceção.

Exemplo

A aplicação apresenta duas caixas de edição e um botão. Ao entrarmos com um número na primeira caixa de edição, este deve ser convertido para inteiro, e mostrando na segunda caixa.

Veja o código do botão Converter:

procedure Tform1.

Button1Click(Sender:tObject);

procedure TForm1.Button1Click(Sender: TObject);

var

   a: Integer;

begin

try

a:=StrtoInt(Edit1.Text);

Edit2.Text:=IntToStr(a)

except

on EconvertError do

Edit2.Text := '0';

end;

end;

Quando, ao executarmos a aplicação, inserimos na primeira caixa de edição o valor de 10,5 um erro é gerado, já que 10,5 não pode ser convertido para inteiro. Este erro é da classe EconvertError. Tratamos este erro, ao colocar na segunda caixa de edição o valor 0, quando o erro ocorre.