Visual Basic, VB .NET, ASP, Active X, Access, SQL Server

Dois Momentos Para Tratar Erros

    Quando um programa trata uma situação de erro ou exceção e precisa enviar um aviso de que algo não ocorreu como deveria, há dois contextos básicos possíveis: o de desenvolvimento e o de uso da aplicação pelo cliente. No contexto de desenvolvimento, o tratamento de erros deve dar uma mensagem que faça sentido para o desenvolvedor. No contexto do cliente, a mensagem - se houver - deve ser dada levando em conta o que interessa ao usuário final. Mas como fazer para que o programa saiba em que contexto está sendo executado?

    A forma simples e econômica de fazer isto é sinalizar o contexto em que a aplicação está sendo executada e usar os recursos da linguagem para dirigir o compilador conforme a sinalização. Para isto, podemos informar na janela 'Project Properties' (veja a seguir) um argumento de compilação condicional que deixaremos com o valor - 1 durante a fase de desenvolvimento. Quando formos criar a versão final do aplicativo, mudaremos o argumento para 0. Abaixo, na janela 'Project Properties', criamos arbitrariamente um argumento com o nome EM_DESENVOLVIMENTO e o igualamos a -1 para sinalizar que estamos na fase de desenvolvimento do aplicativo.

O argumento EM_DESENVOLVIMENTO terá seu valor verificado dentro do tratamento de erros por meio da diretiva de compilação #If. Quando o valor de EM_DESENVOLVIMENTO estiver em -1, será compilado o código para tratar o erro durante a depuração; quando mudarmos o valor de EM_DESENVOLVIMENTO para 0, o código compilado será aquele que se destina à versão final do aplicativo. Em qualquer caso, o código não compilado não fará parte do executável gerado. Veja abaixo um exemplo de como ficaria um tratamento de erros condicional:

Erro:

#If EM_DESENVOLVIMENTO Then

MsgBox "Erro na fase de desenvolvimento"

#Else

MsgBox "Erro na versão final"

#End If

Use Numeração de Linhas

    No Visual Basic há uma propriedade não documentada e desconhecida de muitos programadores, que torna a numeração de linhas um aliado importantíssimo no tratamento de erros. Trata-se da propriedade Erl do VBA. Esta propriedade retorna o número da linha em que último erro ocorreu. Isto dá ao desenvolvedor a possibilidade de ter , nas mensagens de erro que se destinam a ele, o ponto exato em que o erro ocorreu. Chega de ter que percorrer todas as linhas de um procedimento para descobrir em qual delas exatamente está o erro. Claro que você não vai ficar numerando linhas manualmente. Existem vários add-ins que fazem este trabalho para você. Aqui mesmo, no site da Codelines, há o RabJump, que pode ser usado para este trabalho. Veja abaixo como fica o exemplo anterior de tratamento de erros com o uso de numeração de linhas e Erl:

Public Sub Procedimento()

10000 On Error GoTo Erro

10005 Err.Raise 9999

10010 Exit Sub

10015 Erro:

   #If EM_DESENVOLVIMENTO Then

10020       MsgBox "Erro na linha: " & Erl

   #Else

10025       MsgBox "Erro na versão final"

   #End If

End Sub

    Ao detectar o erro, o rotina de tratamento de erros exibirá uma caixa de mensagem do tipo a seguir:

Tenha Um Tratamento de Erros Em Cada Rotina

    Todo erro deve ser tratado localmente, isto é, no procedimento em que ocorre. Não fazer isto pode significar desestabilização para seu aplicativo. Ao tratar o erro dentro do procedimento em que ele ocorreu, você pode restaurar a aplicação às condições em que estava antes das mudanças que ocorreram no procedimento. Após fazer isto, a rotina de tratamento de erros pode gerar um novo erro usando o método Raise do objeto Err. Isto fará com que a rotina que chamou o procedimento atual também seja notificada do erro e o trate no seu escopo. Se tiver que dar uma mensagem para o usuário, deixe para dá-la no procedimento de evento que iniciou toda a fila de chamadas em que o erro ocorreu, assim você evita de aborrecer seu usuário com uma sequência de mensagens de erro.

Salve o Contexto do Erro Antes de Tratá-lo

    Quando um erro ocorre, você deve salvar as informações que pretende usar sobre o erro e limpar o objeto Err chamando o seu método Clear. De outra forma você corre o risco de ver a permanência do erro afetar outros procedimentos que você venha a chamar de dentro do tratamento de erros. Imagine um procedimento que teste por uma condição de erro sem que o erro tenha sido resetado no início do procedimento. Este procedimento topará com um erro que não ocorreu dentro dele, mas sim na rotina que o chamou. Por outro lado, se você confiar na permanência das informações sobre o erro no objeto Err, poderá se ver sem informação alguma sobre o erro após seu tratamento de erros chamar uma rotina cuja execução limpe o objeto Err. Para armazenar as informações sobre o erro, crie variáveis globais para não ter que declará-las dentro de cada procedimento.

(a ser continuado)