Wie Verwenden von Java-Stil in C # wirft Stichwort?

Question

In Java, das throws Stichwort ermöglicht eine Methode zu erklären, dass es nicht eine Ausnahme auf eigenem handhaben, aber es vielmehr den Aufruf der Methode werfen.

Gibt es ein ähnliches Schlüsselwort / Attribut in C #?

Wenn es kein Äquivalent ist, wie kann erreichen Sie das gleiche (oder eine ähnliche) Wirkung?

Answer 1

In Java, müssen Sie entweder eine Ausnahme behandeln oder die Methode als eine Markierung, die es mit dem throws Schlüsselwort werfen kann.

C # nicht über dieses Schlüsselwort oder ein äquivalentes ein, wie in C #, wenn Sie eine Ausnahme nicht verarbeiten, wird es sprudeln, bis gefangen oder wenn nicht gefangen wird es das Programm beenden.

Wenn Sie damit umgehen wollen, dann wieder werfen Sie folgendes tun können:

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

Answer 2

Die op fragen nach dem C # -Äquivalent von Java throws Klausel - nicht das throw Schlüsselwort. Dies wird in Methodensignaturen in Java verwendet, um eine geprüfte Ausnahme angeben kann geworfen werden.

In C # gibt es keine direkte Entsprechung eines Java-geprüfte Ausnahme. C # hat keine Entsprechung Methodensignatur-Klausel.

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

übersetzt

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

Answer 3

Ja, das ist ein alter Thread, aber oft ich alte Threads finden, wenn ich Antworten bin googeln so dass ich dachte ich würde etwas Nützliches hinzufügen, dass ich gefunden habe.

Wenn Sie Visual Studio 2012 verwenden, gibt es ein in Werkzeug gebaut, die verwendet werden können für eine IDE-Ebene zu ermöglichen, „wirft“ äquivalent.

Wenn Sie XML Dokumentation Kommentare verwenden, wie oben erwähnt, dann können Sie mit dem < a href = „http://msdn.microsoft.com/en-us/library/w1htk11d.aspx“> Tag die Art der Ausnahme von der Methode oder Klasse sowie Informationen geworfen geben auf wann oder warum es geworfen.

Beispiel:

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

Hier ist eine Antwort auf eine ähnliche Frage, die ich nur Fond auf bytes.com :

  

Die kurze Antwort ist nein, es gibt keine geprüfte Ausnahmen in C #. Das   Designer der Sprache diskutiert diese Entscheidung in diesem Interview:

     

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

     

Die nächst Sie erhalten können, ist die Tags in der XML zu verwenden,   Dokumentation und verteilen NDoc erzeugte Dokumente mit Ihrem   Code / Baugruppen, so dass andere Leute können, welche Ausnahmen Sie sehen, werfen   (Das ist genau das, was MS tut in der MSDN-Dokumentation). Sie können sich nicht darauf verlassen   auf dem Compiler Sie nicht behandelte Ausnahmen zu sagen, aber wie   können Sie in Java verwendet werden.

Answer 5

Nachdem man durch die meisten Antworten hier, ich möchte ein paar Gedanken hinzuzufügen.

1. Unter Berufung auf XML-Dokumentation Kommentare und andere erwarten vertrauen ist eine schlechte Wahl. Die meisten C # -Code ich kenne nicht Dokument Methoden vollständig und konsistent mit XML-Dokumentation Kommentare. Und dann ist da noch das größere Problem, dass ohne geprüfte Ausnahmen in C #, wie können Sie alle Ausnahmen Ihre Methode für den Zweck Ihres API Benutzers wirft dokumentieren zu wissen, wie sie behandeln alle einzeln? Denken Sie daran, Sie wissen nur über die, die Sie sich mit dem Schlüsselwort throw in Ihrer Implementierung werfen. auch Ausnahmen in Ihrer Methode Implementierung APIs Sie verwenden werfen könnte, dass man nicht über sie wissen, weil sie möglicherweise nicht dokumentiert werden und Sie nicht sie in Ihrer Implementierung der Handhabung, so dass sie angesichts des Anrufers sprengen werde Ihrer Methode. Mit anderen Worten, diese XML-Dokumentationskommentare kein Ersatz für geprüfte Ausnahmen.

2. Andreas verknüpfen ein Interview mit Anders Hejlsberg in den Antworten hier, warum das C # Design-Team gegen geprüfte Ausnahmen beschlossen. Die ultimative Antwort auf die ursprüngliche Frage wird in diesem Interview versteckt:

  

Die Programmierer schützen ihren Code durch das Schreiben versucht überall endlich ist, so dass sie korrekt wieder heraus werden, wenn eine Ausnahme auftritt, aber sie sind nicht wirklich daran interessiert, die Ausnahmen in der Handhabung.

Mit anderen Worten, sollte niemand daran interessiert sein, was Art von Ausnahme für eine bestimmte API erwarten, da Sie gehen zu immer und überall alle von ihnen zu fangen. Und wenn Sie wirklich wollen, über bestimmte Ausnahmen kümmern, wie sie zu handhaben ist bis zu Ihnen und nicht jemand eine Methode Signatur mit so etwas wie die Java wirft Schlüsselwort definieren, bestimmte Ausnahme zwang auf einer API Benutzer Handhabung.

-

Ich persönlich bin hier zerrissen. Ich stimme mit Anders, dass geprüfte Ausnahmen mit löst nicht das Problem, ohne das Hinzufügen von neuen, verschiedenen Problemen. Genau wie mit den XML-Dokumentation Kommentaren, ich sehe selten C # -Code mit allem, was eingewickelt in Versuch schließlich blockiert. Es fühlt sich für mich, obwohl dies in der Tat die einzige Möglichkeit ist, und etwas, das wie eine gute Praxis scheint.

Answer 6

Eigentlich geprüfte Ausnahmen in C # eine gute oder schlechte Sache angesehen werden kann nicht zu haben.

Ich selbst halte es für eine gute Lösung sein, da geprüfte Ausnahmen Sie mit den folgenden Problemen bieten:

1. Technische Ausnahmen von der Business / Domain-Schicht undicht, weil man sie nicht richtig auf dem niedrigen Niveau verarbeiten kann.
2. Sie gehören zu der Methodensignatur, die nicht immer schön, mit API-Design spielen.

Durch die in den meisten größeren Anwendungen werden Sie das folgende Muster oft sehen, wenn überprüft Ausnahmen auftreten:

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

, die im Wesentlichen bedeutet, emuliert die Art und Weise C # /. NET-Griffe alle Ausnahmen.

Answer 7

Sie fragen dazu:

Re-Auslösen einer Ausnahme

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

oder

static void Main() 
    {
        string s = null;

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

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

Answer 8

Es gibt einige flüchtige Ähnlichkeiten zwischen dem .Net CodeContract EnsuresOnThrow<> und das Java throws Deskriptors, daß beide kann als Typ der Ausnahme an den Aufrufer Signal, das von einer Funktion oder ein Verfahren erhöht werden könnte, aber es gibt auch große Unterschiede zwischen 2:

• geht EnsuresOnThrow<> darüber hinaus nur hervorgeht, welche Ausnahmen ausgelöst werden können, sondern sieht auch die Bedingungen, unter denen sie garantiert geworfen werden - dies ziemlich beschwerlich Code in der aufgerufenen Methode sein kann, wenn die Ausnahmebedingung nicht trivial zu identifizieren. Java throws liefert einen Hinweis auf welche Ausnahmen ausgelöst werden könnten (dh IMO der Fokus in .Net innerhalb der Methode ist Verträge, die die throw zu beweisen, während in Java verschiebt sich der Fokus zu dem Anrufer die Möglichkeit der Ausnahme zu bestätigen).
• .Net CC macht nicht den Unterschied zwischen Checked vs Ungeprüfter Ausnahmen, dass Java hat, obwohl der CC Handbuch Abschnitt 2.2.2 nicht erwähnt zu

  

"exceptional Nachbedingungen verwenden nur für jene Ausnahmen, dass ein Anrufer   erwarten sollte als Teil der API "

• In .Net der Anrufer kann bestimmen, ob oder ob nicht irgendetwas mit der Ausnahme zu tun (zum Beispiel durch Verträge zu deaktivieren). In Java, der Anrufer müssen etwas tun , auch wenn es fügt eine throws für die gleiche Ausnahme auf seiner Oberfläche.

-Code Contracts hier manuell