Exception im try-Block werfen statt catch-Block?

Question

Ich habe Code in unserem Projekt geerbt, der so aussieht. Es ist eine Methode in einer Klasse.

protected override bool Load() 
{ 
    DataAccess.SomeEntity record; 

    try 
    { 
     record = _repository.Get(t => t.ID.Equals(ID)); 

     if (record == null) 
     { 
      throw new InvalidOperationException("failed to initialize the object."); 
     } 
     else 
     { 
      this.ID = record.ID; 
      // this.OtherProperty = record.SomeProperty; 
      // etc 
     } 
    } 
    catch (Exception) 
    { 
     throw; 
    } 

    return true; 
} 

Wenn ich dann diese Load-Methode aus meiner UI-Ebene nennen, würde ich wahrscheinlich versuchen catch-Block haben will jede Ausnahme verursacht durch den Ausfall zu fangen die Instanz zu laden, beispielsweise InvalidOperationException, aber der obige Code fühlt sich falsch an.

Wird die InvalidOperationException nicht von der Catch-Anweisung verschluckt? Diese catch-Anweisung wird auch potenzielle Probleme mit _repository.Get sowie mögliche Probleme mit der Einstellung von Eigenschaften, wenn der Datensatz gültig ist, abfangen.

Ich dachte, ich sollte es vielleicht restrukturieren, indem ich mehr try catch-Anweisungen hinzufügen, um die Get-Operation und Eigenschafteneinstellung separat zu behandeln, oder weitere catch-Blöcke mit verschiedenen Ausnahmen hinzufügen, aber ich fragte einen Kollegen, und er schlug vor, dass der Versuch zu fangen ist in diesem Fall irrelevant und sollte vollständig entfernt werden, es mögen verlassen:

protected override bool Load() 
{ 
    DataAccess.SomeEntity record; 

    record = _repository.Get(t => t.ID.Equals(ID)); 

    if (record == null) 
    { 
     throw new InvalidOperationException("failed to initialize the object."); 
    } 
    else 
    { 
     this.ID = record.ID; 
     // this.OtherProperty = record.SomeProperty; 
     // etc 
    } 

    return true; 
} 

ich möchte einige zweite Meinung, habe ich ein Interesse an der Ausnahmebehandlung nehmen, so möchte ich gerade erst begonnen stellen Sie sicher, dass ich es gemäß den Best Practices richtig mache.

Answer 1

Wenn Sie Ausnahmen in der aufrufenden Methode (Ithink) abfangen, sollten Sie nur Ausnahmen abfangen, die Sie erwarten. Wenn die Ausnahme ein Problem für Load() ist, dann werfen Sie eine neue Exception an die aufrufende Methode mit besseren Informationen über die Ausnahme.

Answer 2

Ausgezeichnet! Sie sind definitiv auf dem richtigen Weg. Die vorherige Implementierung hat nichts anderes getan, als Ausnahmen neu zu werfen, was unnötig ist. Sie sollten nur bestimmte Ausnahmen behandeln, die Sie in der Business-Schicht erwarten, andernfalls sollten sie natürlich den Aufruf-Stack bis zur UI-Ebene hochgehen.

Wie am besten Praxis nur wieder Ausnahmen werfen, wenn Sie einige zusätzliche Debug-Informationen hinzugefügt werden soll, in diesem Fall müssen Sie

Answer 3

eine benutzerdefinierte Ausnahme definieren Wenn Sie dies tun:

catch (Exception) 
{ 
    throw; 
} 

Sie behandeln die Ausnahme im Wesentlichen nicht. Das bedeutet jedoch nicht, dass Sie es ignorieren. Die throw-Anweisung wird die Ausnahme auf dem Stapel weiterleiten. Aus Gründen des sauber lesbaren Codes ist Ihr letztes Beispiel viel besser.

Answer 4

Die Ausnahme wird durch die catch Anweisung abgefangen werden, aber da es eine throw Anweisung hat, wird es die Ausnahme wieder heraus zu werfen. Dies hat den gleichen Effekt, als hätten Sie überhaupt keinen Versuch/Fang, also hat Ihr Kollege recht, wenn er vorschlägt, es auszulassen.

Es ist nicht besonders sinnvoll, Code zur Behandlung von Ausnahmebedingungen hinzuzufügen, wenn Sie die Ausnahme in keiner Weise behandeln.

Answer 5

Ich stimme mit Ihrem Kollegen überein, Sie sollten nur Ausnahmen abfangen, von denen Sie wissen, dass sie abgefangen werden müssen. Normalerweise lasse ich jeden Versuch aus, Blöcke zu fangen, es sei denn, ich weiß genau, warum ich es in einer bestimmten Situation brauche. Das liegt daran, dass Sie dazu neigen, die echten Fehler in Ihrem Code zu verbergen, wenn Sie einfach try catch block um alles setzen. Lassen Sie die Fehlerbehandlung so lange deaktiviert, bis Sie sie unbedingt benötigen - beginnen Sie mit einem einzigen globalen Fehlerhandler am höchsten Punkt der Anwendung - wenn dies asp ist.net können Sie das Anwendungsfehlerereignis haken und Fehler dort protokollieren, aber mein Punkt ist, fügen Sie keine try catch-Blöcke hinzu, es sei denn, Sie wissen, warum Sie sie hinzufügen und Code schreiben, der Fehlerfälle behandelt und sie nicht abfängt.

Viel Spaß!