Tratamento de exceção
As diretrizes a seguir ajudam a garantir que sua biblioteca manipula as exceções apropriadamente.
Não manipular erros por capturar exceções não específico, sistema autônomo sistema.exceção, sistema.SystemException e assim por diante, no código de estrutura.
Você pode capturar exceções quando o objetivo de captura a exceção é reemita ou transferência a exceção para um thread diferente. O exemplo de código a seguir demonstra o tratamento de exceções incorreto.
Public Class BadExceptionHandlingExample1
Public Sub DoWork()
' Do some work that might throw exceptions.
End Sub
Public Sub MethodWithBadHandler()
Try
DoWork()
Catch e As Exception
' Handle the exception and
' continue executing.
End Try
End Sub
End Class
public class BadExceptionHandlingExample1
{
public void DoWork()
{
// Do some work that might throw exceptions.
}
public void MethodWithBadHandler()
{
try
{
DoWork();
}
catch (Exception e)
{
// Handle the exception and
// continue executing.
}
}
}
Evite a manipulação de erros por capturar exceções não específico, sistema autônomo sistema.exceção, sistema.SystemException e assim por diante, no código do aplicativo.Há casos em que o tratamento de erros em aplicativos é aceitável, mas tais casos são raros.
Um aplicativo não deve lidar com exceções que podem resultar em um estado inesperado ou explorável. Se você não pode prever todas as possíveis causas de uma exceção e certifique-se de que o código mal-intencionado não é possível explorar o estado resultante do aplicativo, você deve permitir que o aplicativo para terminar, em vez de tratamento da exceção.
Não exclua qualquer exceção especial quando capturar a fim de transferir exceções.
Em vez de criar listas de exceções especiais no seu catch cláusulas, você deve capturar essas exceções que você pode manipular legitimamente. Exceções que você não pode manipular não devem ser tratadas sistema autônomo casos especiais casos especiais nos manipuladores de exceção não-específica. O exemplo de código a seguir demonstra incorretamente testando para exceções especiais para fins de relançá-los.
Public Class BadExceptionHandlingExample2
Public Sub DoWork()
' Do some work that might throw exceptions.
End Sub
Public Sub MethodWithBadHandler()
Try
DoWork()
Catch e As Exception
If TypeOf e Is StackOverflowException Or _
TypeOf e Is OutOfMemoryException Then
Throw
End If
End Try
End Sub
End Class
public class BadExceptionHandlingExample2
{
public void DoWork()
{
// Do some work that might throw exceptions.
}
public void MethodWithBadHandler()
{
try
{
DoWork();
}
catch (Exception e)
{
if (e is StackOverflowException ||
e is OutOfMemoryException)
throw;
// Handle the exception and
// continue executing.
}
}
}
Considere a possibilidade de capturar exceções específicas quando compreender por que será lançada em um determinado contexto.
Você deve capturar essas exceções é possível recuperar de. Por exemplo, um FileNotFoundException que os resultados de uma tentativa de em em aberto um arquivo não existente podem ser tratados por um aplicativo porque ele pode comunicar-se o problema para o usuário e permitir que o usuário especifique um nome de arquivo diferente ou crie o arquivo. Uma solicitação para em em aberto um arquivo que gera um ExecutionEngineException não devem ser tratados como a causa subjacente da exceção não pode ser conhecida com qualquer grau de certeza, e o aplicativo não pode garantir que ele seja seguro continuar executando.
Não use em exagero catch.Exceções sempre devem ter permissão para propagar até o telefonar pilha.
Capturar exceções que você não pode manipular legitimamente oculta informações críticas de depuração.
Use try-finally e evite usar try-catch para código de limpeza.No código de exceção bem escrito, try-finally é muito mais comum que try-catch.
A finalidade de um catch cláusula é para que você possa manipular exceções (por exemplo, por um erro não fatal de registrar registrar registrar em log). A finalidade de um finally cláusula é para que você possa executar código de limpeza independentemente de se uma exceção foi lançada. Se você alocar recursos caros ou limitados, sistema autônomo conexões de banco de dados ou fluxos, você deve colocar o código para liberá-los dentro de um finally bloco.
Prefere usar uma throw vazia quando capturar e relançar a exceção.Esta é a melhor maneira para preservar a pilha de chamadas de exceção.
O exemplo de código a seguir mostra um método que pode lançar uma exceção. Esse método é referenciado nos exemplos posteriores.
Public Sub DoWork(ByVal anObject As Object)
' Do some work that might throw exceptions.
If (anObject = Nothing) Then
Throw New ArgumentNullException("anObject", "Specify a non-null argument.")
End If
' Do work with o.
End Sub
public void DoWork(Object anObject)
{
// Do some work that might throw exceptions.
if (anObject == null)
{
throw new ArgumentNullException("anObject",
"Specify a non-null argument.");
}
// Do work with o.
}
O exemplo de código a seguir demonstra capturar uma exceção e especificando incorretamente quando relançar a exceção. Isso faz com que o rastreamento da pilha apontar para o re-throw sistema autônomo o local do erro, em vez de apontar para o DoWork método.
Public Sub MethodWithBadCatch(ByVal anObject As Object)
Try
DoWork(anObject)
Catch e As ArgumentNullException
System.Diagnostics.Debug.Write(e.Message)
' This is wrong.
Throw e
' Should be this:
' throw
End Try
End Sub
public void MethodWithBadCatch(Object anObject)
{
try
{
DoWork(anObject);
}
catch (ArgumentNullException e)
{
System.Diagnostics.Debug.Write(e.Message);
// This is wrong.
throw e;
// Should be this:
// throw;
}
}
Não manipulam exceções não-compatível compatível com CLS (exceções que não derivado de sistema.exceção) usando um bloco catch sem parâmetros.Idiomas que oferecem suporte a exceções que não são derivadas de exceção estão disponível para manipular essas exceções de conformidade não-CLS.
O .NET estrutura versão 2.0 encapsula não compatível de CLS exceções em uma classe derivada de Exception.
Partes direitos autorais 2005 Microsoft Corporation. Todos os direitos reservados.
Partes direitos autorais Addison-Wesley Corporation. Todos os direitos reservados.
Para obter mais informações sobre diretrizes de design, consulte a "diretrizes de design do estrutura: Catálogo de convenções, idiomas e padrões para bibliotecas do .NET reutilizável"Krzysztof Cwalina e Brad Abrams, publicado pela Addison-Wesley, 2005.
Consulte também
Outros recursos
Diretrizes de Design para desenvolvimento bibliotecas de classe