___ answer431794 ___
Ja, diese Methoden sind ziemlich (*) gleich. Der einzige Unterschied ist, dass es einfach ist, einen Breakpoint in den ersten zu setzen. Ich würde immer mit der Sekunde gehen, es sei denn, ich müsste wirklich dort brechen und nur dort (im Gegensatz zu sofort irgendwelche Ausnahmen dieser Art geworfen wurden, was einfach wäre). Selbst wenn ich das erste Mal verwenden würde, würde ich es in das zweite Formular zurücklegen, bevor ich den Code beginne.
(*) Es mag durchaus Unterschiede geben, wie das JIT mit ihnen umgeht. Der erste wird mit mehr IL enden, was Möglichkeiten für Inlining usw. beeinflussen wird.
EDIT: Ich kann ein bisschen Micro-Benchmarking nicht widerstehen. Es sieht so aus, als hätte try / catch / throw schlechtere Auswirkungen auf die Leistung als nur das Inlining zu deaktivieren:
%Vor%
Kompilieren Sie mit throw ex;
Ergebnisse (drei Läufe):
Einfache Methode: 504, 495, 489
Kein Inlining: 2977, 3060, 3019
versuchen / fangen / werfen: 5274, 4543, 5145
___ qstntxt ___
Wenn alles, was ich tun möchte, ist, die Ausnahme eine Ebene höher zu werfen, wenn es auftritt?
%Vor%
Sind diese beiden Methoden nicht gleich?
Wenn eine Ausnahmebedingung in TryCatch auftritt, wird sie um eine Ebene hochgestuft, und wenn in NoTryCatch eine Ausnahme auftritt, wird die Ausnahmebedingung ebenfalls um eine Stufe erhöht.
Diese Frage kam nach der Verwendung von ReSharper und bemerkte, dass es vorgeschlagen, den try / catch-Block zu entfernen, da es redundant war.
___ answer431786 ___
Diese beiden Methoden sind im Wesentlichen gleich. In diesem Fall war ReSharper mit seinem Vorschlag richtig.
___ answer431787 ___
Nein, du brauchst den Versuch nicht zu fangen. Der einzige Grund, warum Sie die erste Funktion verwenden möchten, ist, wenn Sie einige Protokollierungs- oder Freigabefunktionen ausführen möchten, bevor Sie die Funktion weiter ausführen.
___ answer431936 ___
Sie sind wirklich nicht das Gleiche. throw; allein oder %code% verwirren die Stack-Trace-Informationen und können das Debugging erschweren.
Der beste Grund, eine Ausnahme abzufangen, besteht darin, der Stack-Ablaufverfolgung einen Kontext hinzuzufügen, z. B .:
%Vor%
___ answer431789 ___
ReSharper ist korrekt. Es sei denn, Sie möchten etwas über eine Ausnahme abfangen und tun, es gibt keinen Grund, einen try..catch-Block zu verwenden.
___ answer431792 ___
Wenn Sie nur die Ausnahme erneut auslösen, brauchen Sie den try / catch-Block nicht. Im Allgemeinen sollten Sie Ausnahmen nur abfangen, wenn Sie mit ihnen umgehen können. Ansonsten lassen sie sich nach oben ausbreiten.
___ tag123trycatch ___ try-catch ist ein syntaktisches Konstrukt zum Abfangen von Ausnahmen, die von einem Codeabschnitt ausgelöst werden
___ tag123c ___ C # (sprich "Cis") ist eine objektorientierte Programmiersprache auf hohem Niveau, die für die Erstellung einer Vielzahl von Anwendungen entwickelt wurde, die auf dem .NET Framework (oder .NET Core) ausgeführt werden. C # ist einfach, leistungsfähig, typsicher und objektorientiert.
___ answer431791 ___
Ja, der try catch Block ist redundant. Der Stapel wird nur abgewickelt, bis ein try / catch die Ausnahme behandelt.
___ qstnhdr ___ C # Brauche ich TRY / CATCH um zu werfen?
___ antwort431890 ___
Etwas, über das ich nachgedacht habe, aber ich war mir nicht 100% sicher, also ging ich nachsehen. Ich hatte manchmal Recht.
Offenbar, wenn Sie die Ausnahme erneut werfen, was Ihr Code tut, könnten Sie am Ende die Stack-Trace ändern. Vor allem, wenn Sie %code% schreiben würden, würde das den Stack-Trace zurücksetzen. Zweitens kann es auch beim Schreiben von %code% Fälle geben, in denen Informationen fehlen. Siehe Artikel und einige Benutzerkommentare , die darauf folgen.
Natürlich hängen die meisten dieser Probleme mit den Stack-Trace- und Zeilennummern zusammen, die wichtig sind, aber ich dachte, dies würde sich auch auf die Performance auswirken, nicht nur wegen Inlining (oder deren Fehlen), sondern auch weil von der ganzen Ausnahme fangen und werfen über Kopf, aber ich habe nichts Konkretes gefunden.
___