try-catch-Blöcke mit dem Rückgabetyp

Question

Wenn ich eine Methode, die etwas zurückgibt, wie

public DataTable ReturnSomething() 
{ 
    try 
    { 
     //logic here 
    return ds.Tables[0]; 
    } 
    catch (Exception e) 
    { 
     ErrorString=e.Message; 
    } 
} 

Dieser Compiler-Fehler erzeugt, offensichtlich weil catch{} Block nichts zurückliefert.

Also, wenn ich Methoden mit Rückgabewerten habe, verwende ich nicht try-catch-Block, was eine schlechte Praxis ist. Wenn ein Fehler vorliegt, möchte ich eine Fehlerzeichenfolge für diesen Fehler festlegen. Aber dann brauche ich auch einen Rückgabewert. Rat?

Answer 1

Speichern Sie Ihre Rückgabewert codiert werden:

public DataTable ReturnSomething() 
{ 
    DataTable returnValue = null; 

    try 
    { 
     //logic here 
     returnValue = ds.Tables[0]; 
    } 
    catch (Exception e) 
    { 
     ErrorString=e.Message; 
    } 

    return returnValue; 
} 

Answer 2

Sie sollten die Ausnahme in Ihrem catch-Block auslösen/werfen und in der aufrufenden Methode behandeln.

public void invokeFaultyCode() 
{ 
    try 
    { 
     DataTable dt = ReturnSomething(); 
    } 
    catch(Exception e) 
    { 
     // Print the error message, cleanup, whatever 
    }  
} 
public DataTable ReturnSomething() throws Exception 
{ 
    try 
    { 
     //logic here 
    return ds.Tables[0]; 
    } 
    catch (Exception e) 
    { 
     ErrorString=e.Message; 
     throw; 
    } 
} 

PS: Sorry für Syntaxfehler, ich bin ein bisschen rostig auf C#.

Answer 3

Es hängt von Ihrer Anwendung ab. Sie können null, eine leere DataTable oder was auch immer unter Umständen geeignet ist, zurückgeben.

Answer 4

Sie sollten den Aufrufer mit einem try Catch umwickeln ... alle Ausnahmen, die in der aufgerufenen Routine auftreten, werden zum Aufrufer blasen und Sie können sie dort fangen.

Persönlich denke ich, es ist Overkill, einen Versuch in dieser Routine zu fangen, wie Sie den Anrufer haben sollten, der die Ausnahme behandelt.

Für mein Beispiel würde dies wie folgt ...

in einer temporären Variablen wie diese

private void DoSomething() { 
    try { 
     DataTable dt = ReturnSomething(); 
    } 
    catch (Exception ex) { 
    }  
} 

public DataTable ReturnSomething() { 
    DataTable dt = new DataTable(); 

    // logic here 
    return dt; 
} 

Answer 5

denke ich Ihren Code zur gleichen Zeit laufen wird eine ausreichend hohe Ebene des Aufruf-Stacks und es ist mit UI-Code gemischt. Wenn dies wirklich der Fall ist, könnten Sie return null im Catch-Block. Wenn Sie jedoch wiederverwendbaren Code schreiben, sollten Sie ihn so umgestalten, dass er keine UI-Manipulation enthält und die Ausnahme auf einer höheren Ebene im Aufruf-Stack behandelt.

Answer 6

Da Sie in Ihrem Beispiel die Ausnahme kacheln (und nicht erneut werfen), geht der äußere Code davon aus, dass alles in Ordnung ist und Sie daher etwas Nützliches zurückgeben sollten.

Wenn Sie die Ausnahme dort abfangen müssen und etwas tun, ist alles in Ordnung, aber wenn es immer noch ein Fehlerfall ist, sollten Sie es auch werfen, oder eine andere Ausnahme, vielleicht mit der, die Sie gerade als InnerException abgefangen haben.

Answer 7

ich würde annehmen, dass Sie nach wie vor die Nachricht einstellen, dann null zurück, oder was auch immer die C# entspricht

public DataTable ReturnSomething(){ 
    try { 
     //logic here 
     return ds.Tables[0]; 
    } catch (Exception e) { 
     ErrorString=e.Message; 
     return null; 
    } 
} 

Answer 8

Wie wäre es damit:

public DataTable ReturnSomething(out string errorString) 
{ 
    errorString = string.Empty; 
    DataTable dt = new DataTable(); 
    try 
    { 
     //logic here 
    dt = ds.Tables[0]; 
    } 
    catch (Exception e) 
    { 
     errorString = e.Message; 
    } 
    return dt; 
} 

Answer 9

Wenn Sie das "gehen, um den Kopf Wirf keine Ausnahmeroutine "(was ich nicht unbedingt empfehle), du könntest dem TryParse-Ansatz von MS folgen.

Etwas wie:

private string FillDataTable(out DataTable results) 
{ 

    try 
{ 
    results = new DataTable(); //something like this; 
    return String.Empty; 
} 
catch (Exception ex) 
{ 
    results = null; 
return ex.Message; 

} 

}

Answer 10

Die Variable error sieht verdächtig nach einem Fehlercode Variable. Es empfiehlt sich, Ausnahmen zu verwenden, um Fehlerinformationen direkt zu übermitteln, anstatt sie in Fehlercodes zu speichern.

Sie machen das gleiche mit Ihrem ErrorString, wie Sie es wären, wenn Sie die Ausnahme einfach vom Aufrufer abfangen lassen: die Verantwortung für die Reaktion auf einen Fehler von der Methode selbst zu entfernen. Das ist ein gutes Ziel. Aber die Verwendung einer Fehlerzeichenfolge bringt Ihnen nichts über die Verwendung einer Ausnahme. In der Tat verlieren Sie Informationen auf diese Weise. Es gibt eine Reihe von Arten von Fehlern, die auftreten können, und viele haben spezielle Ausnahmen, die mit ihnen verbunden sind, mit ihren eigenen speziellen Eigenschaften, um kontextabhängige Informationen über den Fehler zu speichern. Wenn Sie die Nachricht in einem String speichern, verlieren Sie diese Information.

Wenn Ihr Ziel also nicht darin besteht, den Fehlertyp des Aufrufers zu verbergen, können Sie nur gewinnen, indem Sie die Ausnahme durchlassen.

Eine andere Sache zu prüfen ist, ob dies wirklich ein Fehlerszenario ist. Wenn dies der Fall ist, ist es sehr unwahrscheinlich, dass Ihre Aufrufmethode überhaupt den Wert des Rückgabewerts berücksichtigt. In diesem Fall müssen Sie sich keine Sorgen machen, indem Sie einfach die Ausnahme loslassen und nichts zurückgeben. Wenn es nicht wirklich ein Fehlerszenario ist, und der Anrufer wird einfach weitermachen und etwas anderes tun, nun, das muss der Anrufer entscheiden, oder? Es gibt immer noch keinen großen Vorteil, wenn Sie eine Fehlerzeichenfolge und eine Dummy-DataTable oder eine Null zurückgeben und die Ausnahme mit all ihren kontextabhängigen Fehlerinformationen überschreiben.

Answer 11

Sie können es wie den folgenden Beispielcode tun.

public DataTable ReturnSomething(out string OutputDesc) 
{ 
    try 
     { 
     //logic here 
     OutputDesc = string.Format("Your Successful Message Here..."); 
     return ds.Tables[0]; 
     } 
     catch (Exception e) 
     { 
     OutputDesc =e.Message; 
     return null; 
     } 

}