C# -  Exception x Error

Hoje veremos os conceitos de Exception e Error e qual a diferença entre eles, se que há alguma diferença.

Geralmente usamos as palavras Exception e Error de forma intercambiável, como se tivessem o mesmo significado.

Mas será que isso esta correto ?

Os conceitos de Exception e Error são mesmo iguais ?

Os conceitos são iguais.

Uma Exception é um erro que é esperado ou conhecido e que pode ser tratado em tempo de execução. Sendo uma condição excepcional que altera o fluxo normal do programa e que pode ser prevista. Ex: Arquivo não encontrado, falha na conexão, falha ao gravar no banco de dados, etc.

Uma exceção é um objeto de um tipo derivado da classe System.Exception. Um SystemException é lançado pelo CLR (Common Language Runtime) quando ocorrem erros não-fatais e recuperáveis pelos programas do usuário.

Um Error é uma ocorrência inesperada que não pode ser tratada em tempo de execução. Representa uma situação anormal que não era esperada.

Assim erros são exceções não verificadas e o desenvolvedor não é obrigado a fazer nada para tratar um erro.

Os erros normalmente tendem a sinalizar o final do programa, normalmente não podem ser recuperados e devem fazer com que você saia do programa atual. Não deve ser tratado ou manuseado.

Assim, todos os erros são exceções, mas o inverso não é verdadeiro. Em geral, os erros são situações que ninguém pode controlar ou prever quando vai ocorrer, por outro lado, uma exceção pode ser prevista e pode ser tratada.

Tipos de Erros

Os runtime errors ou erros de tempo de execução podem ocorrer por várias razões. No entanto, nem todos os erros devem ser tratados como exceções em seu código. Aqui estão algumas categorias de erros que podem ocorrer em tempo de execução e as maneiras apropriadas para responder a eles.

1 -  Erros de uso - Um erro no uso representa um erro na lógica do programa que pode resultar em uma exceção. No entanto, o erro deve ser resolvido não por meio de manipulação de exceção, mas modificando o código com defeito.

2 - Erros de programa - Um erro de programa é um erro de tempo de execução que necessariamente não pode ser evitado, escrevendo código livre de bugs.  Em alguns casos, um erro de programa pode refletir uma condição de erro esperado. Nesse caso, você talvez queira evitar o uso da manipulação de exceção para lidar com o erro de programa e em vez disso, repetir a operação.

Em outros casos, um erro de programa reflete uma condição de erro inesperado que pode ser tratado em seu código. Por exemplo, mesmo se você tiver verificado que exista um arquivo, ele pode ser excluído antes que você possa abri-lo ou ele pode estar corrompido. Nesse caso, tentando abrir o arquivo, criando um objeto StreamReader ou chamando o método Open pode lançar uma exceção FileNotFoundException. Nesses casos, você deve usar um tratamento de exceções para recuperar o erro.

3- Falhas de sistema - Uma falha do sistema é um erro de tempo de execução que não pode ser mantido por meio de programação de forma significativa. Por exemplo, qualquer método pode acionar uma exceção do tipo OutOfMemoryException se a common language runtime não puder alocar memória adicional. Em geral, falhas de sistema não são controladas por meio de tratamento de exceção. Em vez disso, você poderá usar um evento, como AppDomain.UnhandledException e chamar o método Environment.FailFast para registrar informações de exceção e notificar o usuário sobre a falha antes do encerramento do aplicativo.

Classes de Exceções

Uma dos pontos básicos para um software robusto é um bom tratamento de exceções. É uma boa prática sempre estar na defesa como seu código. Você tem que supor que tudo pode falhar e atuar de forma a prever e tratar os possíveis casos onde as exceções podem ocorrer. Assim se você precisa abrir um arquivo para realizar uma operação tem que prever situações nais quais a localização e a abertura do arquivo podem falhar.

Se você não lidar com possíveis cenários de erro, inevitavelmente eles acontecerão e seus usuários terão problemas., alguns deles podem ser erros do usuário e pode não haver nada que você possa fazer sobre eles.

As exceções C# são representadas por classes. As classes de exceção em C# são direta ou indiretamente derivadas da classe System.Exception.

A classe Exception é a classe base da qual todas as outras exceções herdam e ela fornece várias propriedades úteis que auxiliam no tratamento de exceções:

- StackTrace: um rastreamento de pilha para ver exatamente onde ocorreu a exceção.
- InnerException: Útil quando as exceções estão encadeadas. Isso permite que um tipo de exceção lance outro tipo de exceção, ad infinitum.
- Message: A mensagem detalhada indicando o que aconteceu.
- Data: Um dicionário que pode ser usado para armazenar dados arbitrários associados a essa instância de exceção específica.

Algumas das classes de exceção derivadas da classe System.Exception são as classes System.ApplicationException e System.SystemException.

A tabela a seguir fornece algumas das classes de exceção predefinidas derivadas da classe Sytem.SystemException :

Classe de Exceção e Descrição
System.IO.IOException - Trata erro de I/O.
System.IndexOutOfRangeException - Trata erro gerado por uma referência a um índice de um array fora do escopo.
System.ArrayTypeMismatchException - Trata erros gerados quando o tipo incompatível com o tipo Array.
System.NullReferenceException - Trata erros gerados a partir da referência a objetos null.
System.DivideByZeroException - Trata erros gerados pela divisão por zero.
System.InvalidCastException - Trata erros gerados durante a conversão de tipos
System.OutOfMemoryException - Trata erros gerados a partir de memória insuficiente
System.StackOverflowException - Trata erro gerados a partir do estoura da pilha

Você deve derivar suas exceções personalizadas da classe Exception em vez da classe ApplicationException. Assim, você não deve lançar uma exceção ApplicationException em seu código e não deve capturar uma exceção ApplicationException, a menos que pretenda lançar novamente a exceção original.

Uma razão simples para isso é que existem outras classes de exceção na plataforma .NET derivadas de ApplicationException. Se você lançar ApplicationException em seu código e capturá-la mais tarde, também poderá capturar as exceções derivadas que podem interromper seu aplicativo.

E se você pretende gerar uma exceção personalizada considere usar um tipo de exceção existente no .NET Framework em vez de fazer a sua implementação.

A seguir temos alguns dos principais tipos de exceções comuns e as condições sob as quais gerá-los:

  1. ArgumentException - Um argumento não nulo é passado para um método é inválido.
  2. ArgumentNullException -  Um argumento que é passado para um método é null.
  3. ArgumentOutOfRangeException - Um argumento está fora do intervalo de valores válidos.
  4. FileNotFoundException - Um arquivo não existe.
  5. FormatException - Um valor não está em um formato apropriado para ser convertido de uma string por um método de conversão, como Parse.
  6. InvalidOperationException - Uma chamada de método é inválida no estado atual do objeto.
  7. IndexOutOfRangeException - Um índice está fora dos limites de uma matriz ou coleção.
  8. NotImplementedException - Uma operação ou método não está implementada.
  9. NotSupportedException - Não há suporte para um método ou operação.
  10. TimeoutException - O intervalo de tempo alocado para uma operação expirou.

Você deve considerar a implementação de exceções personalizadas nos seguintes cenários:

  1. Quando a exceção reflete um erro de programa exclusivo que não pode ser mapeado para uma exceção do .NET Framework existente;
  2. Quando a exceção requer tratamento que é diferente do tratamento adequado para uma exceção do .NET Framework existente ou a exceção deve ter a ambiguidade removida de uma exceção semelhante;

Nestes casos um roteiro básico a seguir seria:

Evite lancar exceções

Lançar ou manipular uma exceção consome uma quantidade significativa de recursos do sistema e de tempo de execução. 

Você deve lançar exceções somente para lidar com condições realmente extraordinárias e não para manipular eventos previsíveis ou de fluxo de controle. Assim você não deve gerar uma exceção para entradas inválidas do usuário e sim deve direcionar os usuários para inserir novamente os dados.

E estamos conversados...

"E também todos os que piamente querem viver em Cristo Jesus padecerão perseguições.
Mas os homens maus e enganadores irão de mal para pior, enganando e sendo enganados."
2 Timóteo 3:12,13

Veja os Destaques e novidades do SUPER DVD Visual Basic (sempre atualizado) : clique e confira !

Quer migrar para o VB .NET ?

Quer aprender C# ??

Quer aprender os conceitos da Programação Orientada a objetos ?

Quer aprender o gerar relatórios com o ReportViewer no VS 2013 ?

Referências:

José Carlos Macoratti