Come usare Java in stile getta parola chiave in C #?

Question

In Java, il throws parola chiave permette un metodo a dichiarare che non gestirà un'eccezione di per sé, ma piuttosto gettarlo al metodo chiamante.

C'è una simile parola / attributo in C #?

Se non esiste un equivalente, come si può ottenere lo stesso (o simile) effetto?

Answer 1

In Java, è necessario gestire un'eccezione o contrassegnare il metodo come uno che può buttare utilizzando la parola chiave throws.

C # non ha questa parola chiave o una equivalente, come in C #, se non gestire un'eccezione, lo farà bolla, fino catturati o, se non lo prese terminerà il programma.

Se si desidera gestire poi ri-lanciare è possibile effettuare le seguenti operazioni:

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

Answer 2

Il PO sta chiedendo circa la C # equivalente di Java clausola throws - non la parola chiave throw. Questo è usato in metodi firme in Java per indicare un'eccezione controllata può essere gettata.

In C #, non esiste un equivalente diretto di un Java verificata un'eccezione. C # non ha alcuna clausola di firma del metodo equivalente.

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

si traduce in

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

Answer 3

Sì, questo è un thread vecchio, ma mi capita spesso di trovare vecchie discussioni quando sto googling risposte così ho pensato che vorrei aggiungere qualcosa di utile che ho trovato.

Se si utilizza Visual Studio 2012 v'è una costruito in strumento che può essere utilizzato per consentire un livello di IDE "getta" equivalente.

Se si utilizza Commenti , come detto sopra, quindi è possibile utilizzare il < a href = "http://msdn.microsoft.com/en-us/library/w1htk11d.aspx"> tag per specificare il tipo di eccezione generata dal metodo o di classe, nonché informazioni su quando e perché si è gettato.

Esempio:

    /// <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

Ecco una risposta ad una domanda simile ho appena fondo su bytes.com :

  

La risposta breve è no, ci sono delle eccezioni non controllato in C #. Il   progettista della lingua discute questa decisione in questa intervista:

     

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

     

Il più vicino si può ottenere è quello di utilizzare i tag nella tua XML   la documentazione, e distribuire NDoc generato Documenti con il tuo   Codice / assiemi in modo che altre persone possano vedere quali eccezioni si passi   (Che è esattamente ciò che MS fare nella documentazione MSDN). Non si può contare   il compilatore per raccontarvi le eccezioni non gestite, tuttavia, come   si può essere abituati in java.

Answer 5

Dopo aver attraversato la maggior parte delle risposte qui, vorrei aggiungere un paio di pensieri.

1. Basandosi sulla documentazione XML Commenti e in attesa di altri a fare affidamento su è una scelta sbagliata. La maggior parte del codice C # che ho incontrato non si metodi di documenti completamente e in modo coerente con la documentazione XML Commenti. E poi c'è il problema più grande che senza eccezioni controllate in C #, come hai potuto documentare tutte le eccezioni il metodo getta allo scopo di all'API dell'utente per sapere come gestire tutti singolarmente? Ricordate, si sa solo di quelli che da soli lanciare con la parola chiave tiro nell'implementazione. Apis si sta utilizzando all'interno della vostra implementazione del metodo potrebbe anche generare eccezioni che non si conoscono perché non potrebbero essere documentati e non li stai gestione nell'implementazione, in modo da faranno saltare in aria di fronte al chiamante del vostro metodo. In altre parole, questi commenti di documentazione XML non sono sostituto per eccezioni controllate.

2. Andreas legato un colloquio con Anders Hejlsberg nelle risposte qui sul motivo per cui il team di progettazione C # deciso contro eccezioni controllate. La risposta definitiva alla domanda iniziale è nascosto in quell'intervista:

  

I programmatori proteggere il loro codice scrivendo try infine è ovunque, così faranno tornare indietro correttamente se si verifica un'eccezione, ma non sono realmente interessati nella gestione delle eccezioni.

In altre parole, nessuno dovrebbe essere interessato a che tipo di eccezione si può aspettare per una particolare API come si sta andando sempre di catturare tutti loro in tutto il mondo. E se si vuole veramente a particolari eccezioni, come gestirli sta a voi e non qualcuno la definizione di un metodo di firma con qualcosa come il Java getta parola chiave, costringendo particolare la gestione su un utente API un'eccezione.

-

Personalmente, sto lacerato qui. Sono d'accordo con Anders che avere eccezioni controllate non risolve il problema senza l'aggiunta di nuove, problemi diversi. Proprio come con i commenti di documentazione XML, vedo raramente codice C # con tutto avvolto in try infine blocchi. Ci si sente a me, però questo è davvero l'unica opzione e qualcosa che sembra una buona pratica.

Answer 6

In realtà eccezioni non aver controllato in C # può essere considerato un bene o male.

Mi considero una buona soluzione in quanto eccezioni controllate forniscono i seguenti problemi:

1. Eccezioni tecniche che perde per lo strato di business / dominio perché non è possibile gestire in modo adeguato al livello basso.
2. Appartengono alla firma del metodo che non sempre piacevole giocare con il design API.

A causa di ciò, nella maggior parte delle applicazioni più grandi si vedrà il seguente schema spesso quando si verificano eccezioni controllate:

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

Il che significa essenzialmente simulare il modo in C # /. NET maniglie tutte le eccezioni.

Answer 7

Le domande in questo modo:

Re-lanciare un'eccezione

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

o

static void Main() 
    {
        string s = null;

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

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

Answer 8

Ci sono alcune somiglianze tra fugaci .Net CodeContract EnsuresOnThrow<> e il descrittore java throws, in quanto entrambe può segnalare al chiamante come il tipo di eccezione che potrebbe essere sollevato da una funzione o metodo, anche se ci sono anche importanti differenze tra 2:

• EnsuresOnThrow<> va oltre la semplice affermando che le eccezioni possono essere gettati, ma stabilisce anche le condizioni in cui essi sono garantiti per essere gettato - questo può essere il codice abbastanza oneroso nel metodo chiamato se la condizione di eccezione non è banale da identificare. Java throws fornisce un'indicazione dei quali eccezioni potrebbero essere gettati (vale a dire la messa a fuoco IMO NET è all'interno del metodo che i contratti per dimostrare la throw, mentre in Java l'attenzione si sposta al chiamante di riconoscere la possibilità di eccezione).
• Net CC non fa la distinzione tra Controllato vs non controllato eccezioni che Java ha, anche se la sezione del manuale CC 2.2.2 fa menzione a

  

"utilizzare postcondizioni eccezionali solo per quelle eccezioni che un chiamante   deve aspettare come parte della API "

• In .Net il chiamante può determinare se o non fare nulla con l'eccezione (ad esempio disattivando contratti). In Java, il chiamante deve fare qualcosa , anche se si aggiunge un throws per la stessa eccezione sulla sua interfaccia.

codice dei contratti manuale qui