Lançamento de exceção

Exceções são lançadas quando um membro não puder fazê com êxito o que é projetado para fazer. Isso é conhecido sistema autônomo falha de execução. Por exemplo, se o Connect método não pode se conectar 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 meio principal de relatar erros em estruturas.

Diretrizes de design para exceções Discute vários benefícios que você obter usando exceções.

Fazer execução falhas de relatório, gerar exceções.Se um membro não pode fazer com êxito o que é 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 sistema.ambiente.FailFast(sistema.String) (um recurso do .NET estrutura versão 2.0) em vez de gerar uma exceção, se o seu código encontrar uma situação em que é não seguro continuar executando.

Não use exceções para o fluxo normal de controle, se possível.Exceto para operações com as condições de corrida potencial e falhas do sistema, designers do estrutura devem projetar APIs de forma que os usuários podem gravar código lança exceções.Por exemplo, você pode fornecer uma maneira de verificar condições antes de chamar um membro, para que os usuários possam gravar código lança exceções.

O exemplo de código a seguir demonstra a testes para evitar exceções de ser lançada quando uma seqüência de mensagem é null (Nothing no 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);
            }
        }
    }
}

Para obter informações adicionais sobre padrões de design que pode reduzir o número de exceções lançadas, consulte o Desempenho e exceções.

Considere as implicações de desempenho de gerar exceções.

Faça todas sistema autônomo 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 sistema autônomo parte de seu contrato de documentos.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, sistema autônomo o seguinte:

Private Function ParseUri(ByVal uriValue As String, ByVal throwOnError As Boolean) As Uri

Uri ParseUri(string uriValue, bool throwOnError)

Não tem membros públicos que retornam exceções sistema autônomo o valor retornado ou sistema autônomo 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 criar e inicializar exceções.

Considere o uso de métodos de construtor de exceção.É comum para lançar a exceção mesma de locais diferentes.Para evitar inchaço do código, use métodos auxiliares que criar exceções e inicializar suas propriedades.

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 lança exceções de blocos de filtro de exceção.Quando um filtro de exceção gerará uma exceção, a exceção é detectada pelo common linguagem tempo de execução (CLR) e o filtro retorna false.Esse comportamento é idêntico do filtro de execução e retornando false explicitamente e, portanto, é muito difícil depurar.

Alguns idiomas such sistema autônomo translation from VPE for Csharp não oferecem suporte a filtros de exceção.

Evite explicitamente gerar exceções de blocos finally.Exceções geradas implicitamente resultantes da chamada dos métodos que lançar são aceitáveis.

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

Conceitos

Escolhendo o tipo correto de exceção para lançar

Outros recursos

Diretrizes de Design para desenvolvimento bibliotecas de classe

Diretrizes de design para exceções