Lançamento de exceção
Exceções são lançadas quando um membro não pode fazer com êxito, ele é projetado para fazer. Isso é conhecido como falha de execução. Por exemplo, se a Connect método não pode conectar com o ponto de extremidade remoto especificado, esta é uma falha de execução e uma exceção é lançada.
As diretrizes a seguir ajudam a garantir que você lançar exceções quando apropriado.
Não retornam os códigos de erro. As exceções são o principal meio de relatórios de erros em estruturas.
Diretrizes de design para exceçõesDiscute vários benefícios que você obter usando exceções.
Relatório do falhas de execução, Lançando exceções. Se um membro não pode fazer com êxito, ele é projetado para fazer, que deve ser considerado uma falha de execução e deve ser lançada uma exceção.
Considere a possibilidade de encerrar o processo chamando System.Environment.FailFast(System.String) (um arquivo.Recurso do NET Framework versão 2.0) em vez de gerar uma exceção se o seu código encontra uma situação onde é seguro continuar a execução.
Não use exceções para o fluxo normal de controle, se possível. Exceto para falhas do sistema e operações com possíveis condições de corrida, os designers do framework devem projetar APIs para que os usuários podem gravar código não lançar exceções. Por exemplo, você pode fornecer uma maneira de verificação das pré-condições antes de chamar um membro, de modo que os usuários podem gravar código não lançar exceções.
O exemplo de código a seguir demonstra os testes para evitar exceções de ser lançada quando uma seqüência de mensagem é null (Nothing em Visual Basic).
Public Class Doer
' Method that can potential throw exceptions often.
Public Shared Sub ProcessMessage(ByVal message As String)
If (message = Nothing) Then
Throw New ArgumentNullException("message")
End If
End Sub
' Other methods...
End Class
Public Class Tester
Public Shared Sub TesterDoer(ByVal messages As ICollection(Of String))
For Each message As String In messages
' Test to ensure that the call
' won't cause the exception.
If (Not (message) Is Nothing) Then
Doer.ProcessMessage(message)
End If
Next
End Sub
End Class
public class Doer
{
// Method that can potential throw exceptions often.
public static void ProcessMessage(string message)
{
if (message == null)
{
throw new ArgumentNullException("message");
}
}
// Other methods...
}
public class Tester
{
public static void TesterDoer(ICollection<string> messages)
{
foreach (string message in messages)
{
// Test to ensure that the call
// won't cause the exception.
if (message != null)
{
Doer.ProcessMessage(message);
}
}
}
}
public ref class Doer
{
public:
// Method that can potential throw exceptions often.
static void ProcessMessage(String^ message)
{
if (message == nullptr)
{
throw gcnew ArgumentNullException("message");
}
}
// Other methods...
};
public ref class Tester
{
public:
static void TesterDoer(ICollection<String^>^ messages)
{
for each (String^ message in messages)
{
// Test to ensure that the call
// won't cause the exception.
if (message != nullptr)
{
Doer::ProcessMessage(message);
}
}
}
};
Para obter informações adicionais sobre os padrões de design pode reduzir o número de exceções lançadas, consulte o Exceções e desempenho.
Considere as implicações de desempenho de gerar exceções.
Faça todas as exceções lançadas por membros publicamente acessível devido à violação do membro de contrato (em vez de uma falha do sistema) e tratá-los como parte do seu contrato de documento. Exceções que fazem parte do contrato não devem alterar de uma versão para a próxima.
Não tem membros públicos que podem lançar ou não lançar exceções com base em alguma opção.
Por exemplo, não defina membros como, por exemplo, o seguinte:
Private Function ParseUri(ByVal uriValue As String, ByVal throwOnError As Boolean) As Uri
Uri ParseUri(string uriValue, bool throwOnError)
Uri^ ParseUri(String^ uriValue, bool throwOnError)
Não tem membros públicos que retornam exceções, como o valor de retorno ou como um parâmetro de saída.
Essa diretriz é para os membros publicamente visíveis. É aceitável o uso de um método auxiliar particular para construir e inicializar as exceções.
Considere o uso de métodos do construtor de exceção. É comum lançar a mesma exceção de locais diferentes. Para evitar inchaço ao código, use os métodos auxiliares que criar exceções e suas propriedades de inicializar.
O método auxiliar não deve lançar a exceção ou o rastreamento de pilha não refletir com precisão a pilha de chamadas que causou a exceção.
Não jogue exceções em blocos de filtro de exceção. Quando um filtro de exceção gera uma exceção, a exceção é detectada pelo common language runtime (CLR) e o filtro retorna false. Esse comportamento é distinguível em filtro de execução e retornando false explicitamente e, portanto, é muito difícil de depurar.
Algumas linguagens como, por exemplo, C# não suportam filtros de exceção.
Evite explicitamente lançar exceções a partir de blocos finally. Exceções implicitamente geradas, resultante da chamada de métodos lançam são aceitáveis.
Portions Copyright 2005 Microsoft Corporation. Todos os direitos reservados.
Portions Copyright Addison-Wesley Corporation. Todos os direitos reservados.
Para obter mais informações sobre as diretrizes de design, consulte a "diretrizes de Design do Framework: Convenções, idiomas e padrões de reutilizável.Bibliotecas de rede" catálogo por Krzysztof Cwalina e Brad Abrams, publicado pela Addison-Wesley, 2005.
Consulte também
Conceitos
Escolhendo o tipo certo de exceção a ser lançada
Outros recursos
Diretrizes de Design para desenvolvimento bibliotecas de classe