Como usar a palavra-chave throws no estilo Java em C#?

Question

Em Java, o throws A palavra-chave permite que um método declare que não tratará uma exceção por conta própria, mas sim a lançará no método de chamada.

Existe uma palavra-chave/atributo semelhante em C#?

Se não houver equivalente, como você pode conseguir o mesmo efeito (ou semelhante)?

Answer 1

Em Java, você deve lidar com uma exceção ou marcar o método como aquele que pode jogá -lo usando o throws palavra -chave.

C# não possui essa palavra -chave ou equivalente, como em C#, se você não lidar com uma exceção, ela borbulhará, até que seja pega ou, se não for pego, será encerrado o programa.

Se você quiser lidar com isso, novamente se refiro, poderá fazer o seguinte:

try
{
  // code that throws an exception
}
catch(ArgumentNullException ex)
{
  // code that handles the exception
  throw;
}

Answer 2

O OP está perguntando sobre o C# equivalente a Java's throws cláusula - não o throw palavra -chave. Isso é usado nas assinaturas de método em Java para indicar que uma exceção verificada pode ser lançada.

Em C#, não há equivalente direto de uma exceção de verificação de Java. C# não possui cláusula de assinatura de método equivalente.

// Java - need to have throws clause if IOException not handled
public void readFile() throws java.io.IOException {
  ...not explicitly handling java.io.IOException...
}

traduz para

// C# - no equivalent of throws clause exceptions are unchecked
public void ReadFile() 
{
  ...not explicitly handling System.IO.IOException...
}

Answer 3

Sim, este é um tópico antigo, no entanto, frequentemente encontro threads antigos quando estou pesquisando respostas no Google, então imaginei que adicionaria algo útil que encontrei.

Se você estiver usando o Visual Studio 2012, existe uma ferramenta embutida que pode ser usada para permitir um equivalente ao nível de IDE "lança".

Se você usar Comentários da documentação XML, como mencionado acima, você pode usar o u003Cexception> Tag para especificar o tipo de exceção lançada pelo método ou classe, bem como informações sobre quando ou por que ela é lançada.

exemplo:

    /// <summary>This method throws an exception.</summary>
    /// <param name="myPath">A path to a directory that will be zipped.</param>
    /// <exception cref="IOException">This exception is thrown if the archive already exists</exception>
    public void FooThrowsAnException (string myPath)
    {
        // This will throw an IO exception
        ZipFile.CreateFromDirectory(myPath);
    }

Answer 4

Aqui está uma resposta para uma pergunta semelhante que acabei de financiar bytes.com:

A resposta curta é não, não há exceções verificadas em C#. O designer do idioma discute essa decisão nesta entrevista:

http://www.artima.com/intv/handcuffs.html

O mais próximo que você pode obter é usar as tags na sua documentação XML e distribuir documentos gerados pelo NDOC com seu código/assemblies para que outras pessoas possam ver quais exceções você joga (que é exatamente o que o MS fazem na documentação do MSDN). Você não pode confiar no compilador para falar sobre exceções não tratadas, no entanto, como você pode estar acostumado em Java.

Answer 5

Depois de analisar a maioria das respostas aqui, gostaria de acrescentar algumas reflexões.

1. Confiar nos comentários da documentação XML e esperar que outros confiem é uma má escolha.A maior parte do código C# que encontrei não documenta métodos completa e consistentemente com comentários de documentação XML.E há o problema maior: sem exceções verificadas em C#, como você poderia documentar todas as exceções que seu método lança para que o usuário da API saiba como lidar com todas elas individualmente?Lembre-se de que você só conhece aqueles que usa a palavra-chave throw em sua implementação.As APIs que você está usando na implementação do seu método também podem lançar exceções que você não conhece, porque elas podem não estar documentadas e você não as está manipulando em sua implementação, então elas explodirão na frente do chamador do seu método.Em outras palavras, esses comentários da documentação XML não substituem as exceções verificadas.

2. Andreas vinculou uma entrevista com Anders Hejlsberg nas respostas aqui sobre por que a equipe de design do C# decidiu contra as exceções verificadas.A resposta final à pergunta original está escondida naquela entrevista:

Os programadores protegem seu código escrevendo try finalmente em todos os lugares, para que eles recuem corretamente se ocorrer uma exceção, mas na verdade não estão interessados ​​em lidar com as exceções.

Em outras palavras, ninguém deve estar interessado em que tipo de exceção pode ser esperada para uma API específica, pois você sempre encontrará todas elas em todos os lugares.E se você realmente quiser se preocupar com exceções específicas, como lidar com elas depende de você e não de alguém que define uma assinatura de método com algo como a palavra-chave Java throws, forçando o tratamento de exceções específicas em um usuário da API.

--

Pessoalmente, estou dividido aqui.Concordo com Anders que verificar exceções não resolve o problema sem adicionar problemas novos e diferentes.Assim como acontece com os comentários da documentação XML, raramente vejo código C# com tudo agrupado em blocos try finalmente.Parece-me que esta é realmente sua única opção e algo que parece uma boa prática.

Answer 6

Na verdade, não ter exceções verificadas em C# pode ser considerado uma coisa boa ou ruim.

Eu mesmo considero que é uma boa solução, pois as exceções verificadas fornecem os seguintes problemas:

1. Exceções técnicas vazando para a camada de negócios/domínio, porque você não pode lidar com elas corretamente no nível baixo.
2. Eles pertencem à assinatura do método, que nem sempre é agradável com o design da API.

Por causa disso, na maioria dos aplicativos maiores, você verá o seguinte padrão frequentemente quando ocorrem exceções verificadas:

try {
    // Some Code
} catch(SomeException ex){
    throw new RuntimeException(ex);
}

O que significa essencialmente imitar a maneira como C#/. A rede lida com todas as exceções.

Answer 7

Você está perguntando sobre isso:

Representando uma exceção

public void Method()
{
  try
  {
      int x = 0;
      int sum = 100/x;
  }
  catch(DivideByZeroException e)
  {
      throw;
  }
}

ou

static void Main() 
    {
        string s = null;

        if (s == null) 
        {
            throw new ArgumentNullException();
        }

        Console.Write("The string s is null"); // not executed
    }

Answer 8

Existem algumas semelhanças fugazes entre o .NET CodecOntract EnsuresOnThrow<> e o java throws O descritor, pois ambos podem sinalizar para o chamador como o tipo de exceção que pode ser levantada a partir de uma função ou método, embora também haja grandes diferenças entre os 2:

• EnsuresOnThrow<> Vai além de apenas afirmar quais exceções podem ser lançadas, mas também estipula as condições sob as quais elas são garantidas - esse pode ser um código bastante onerosa no método chamado se a condição de exceção não for trivial para identificar. Java throws fornece uma indicação de que exceções podem ser jogadas (ou seja, o foco no .NET está dentro do método que se contrai para provar o throw, enquanto em Java o foco muda para o chamador para reconhecer a possibilidade da exceção).
• .Net CC não faz a distinção entre Verificado vs desmarcado exceções que Java tem, embora o manual do CC Seção 2.2.2 menciona a

"Use pós -condicionas excepcionais apenas para aquelas exceções que um chamador deve esperar como parte da API"

• No .NET, o chamador pode determinar se deve ou não fazer qualquer coisa com a exceção (por exemplo, desativando contratos). Em Java, o chamador devo fazer algo, mesmo que adicione um throws para a mesma exceção em sua interface.

Manual de contratos de código aqui