2008-12-03 4 views
9

In einem Webservice sehe ich diesen Code:Warum eine Ausnahme fangen, nur um sie erneut zu werfen?

<WebMethod()> _ 
Public Function dosomething() As Boolean 
    Try 
     If successful Then 
      Return True 
     Else 
      Return False 
     End If 
    Catch ex As Exception 
     Throw ex 
    End Try 
End Function 

Was ist der Sinn der Ausnahme abfangen und wieder werfen sie nur? Vermisse ich etwas?

Bearbeiten: Danke für die Antworten! Ich dachte, es wäre so etwas, aber ich war mir nicht sicher, ob ich diese ohne irgendwelche Implikationen umgestalten könnte.

Antwort

11

Ich kann keinen Grund, dies für die Funktionalität zu tun. Es kann jedoch auftreten, wenn zuvor eine Fehlerbehandlung (normalerweise Protokollierung) stattgefunden hat und der Entwickler die Protokollbehandlung entfernt, den Code jedoch nicht umstrukturiert hat, um den redundanten try/catch zu entfernen.

5

Wahrscheinlich ein bisschen Code übrig von Debugging (Sie würden einen Haltepunkt auf den Wurf setzen, so dass Sie die Ausnahme im Debugger untersuchen könnten). Ich könnte so etwas tun, wenn ich die Ausnahme protokollieren und dann die Kette weitergeben möchte, obwohl ich wahrscheinlich die Ausnahme in eine andere mit einer aussagekräftigeren (für meine Anwendung) Fehlermeldung einpacken würde.

40

Tun Sie dies nicht.

Wenn Sie unbedingt die Ausnahme erneut auslösen müssen, verwenden Sie einfach throw; mit throw ex; löscht die Stack-Trace und ist absolut falsch.

+0

was ein weiterer Grund ist, warum ich es als innere Ausnahme wickeln würde, wenn ich für die Protokollierung dies tun musste. – tvanfosson

+0

Warum? Werfen Sie einfach die ursprüngliche Ausnahme. Protokollierung sollte nichts ändern oder verändern. – GEOCHET

+3

Um meine eigene Semantik zu der Ausnahme hinzuzufügen. Ex.Ich bekomme eine SqlException, weil ich versuche, eine Zeile mit einem doppelten Primärschlüssel einzufügen. In meiner Methode weiß ich, welche Art von Objekt und welcher Schlüsselwert eingefügt wird. Ich kann eine bessere Ausnahmebedingungsnachricht schreiben, aber immer noch alle Informationen behalten. – tvanfosson

-8

Sie können es tun, wenn Sie eine Ausnahme außer einer Unterklasse davon abfangen möchten.

Zum Beispiel

try { 
    // Something stupid 
} 
catch(RuntimeException e) { 
    throw e; //Handle it outside 
} 
catch (Exception e) { 
    // I'm dead 
} 
+2

Aber du willst immer noch nicht "throw e" nennen. Sie möchten stattdessen "werfen". Der Aufruf von "throw e" lässt die Stack-Informationen bis zu diesem Punkt fallen und es ist gefährlich. –

+2

WRONG WRONG WRONG. BITTE ERKLÄREN NICHT LEUTE DIESE. – GEOCHET

+0

Der Wurf e; ist offensichtlich falsch, aber abgesehen davon ist dies eine interessante Idee. Nicht sicher, ob es einen Anwendungsfall dafür gibt .... – Quibblesome

3

Einer der Architekturen (design patterns) ich dies in verwendet werden sehen konnte, wo eine Transaktion abgewickelt wird. Die Funktion führt ihre Arbeit aus, schlägt fehl, und der catch-Block schließt die Transaktion in einen bekannten Zustand (normalerweise ein Rollback) ab und löst dann eine benutzerdefinierte Ausnahme aus.

So wie es jetzt steht, diesen Code in einen vernünftigeren Zustand umwandeln.

1

Nicht nur der Versuch/Fang ist sinnlos, sondern auch die IF. Die gesamte Funktion könnte auf eine Zeile reduziert werden:

An welcher Stelle, warum stören? Warum nicht einfach "erfolgreich" testen, anstatt die Funktion aufzurufen?

Nun, okay, es ist eine Web-Methode, ich denke, Sie brauchen die Funktion, nur um Ajax oder wen auch immer ein Griff zu geben.

(Ja, ich bin mir bewusst, meine Antwort ist 7 Jahre zu spät. Ich auf diese nur gestolpert, wenn etwas völlig unabhängig zu suchen.)

-2

Das Muster für Monitor macht dies sehr wahrscheinlich einen Fehler erneut auslösen, wie Sie benötigen ein schließlich wird, um sicherzustellen, Monitor.Exit

genannt

https://msdn.microsoft.com/en-us/library/4tssbxcw(v=vs.110).aspx

Dim lockObj As New Object() 

If Monitor.TryEnter(lockObj) Then 
    Try 
     ' The critical section. 
    Catch 
     throw 
    Finally 
     ' Ensure that the lock is released. 
     Monitor.Exit(lockObj) 
    End Try 
End If