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;
   }
}

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

Wenn ich also Methoden mit Rückgabewerten habe ich nicht verwenden try-catch-Block, der eine schlechte Praxis ist. Wenn ein Fehler auftritt, würde Ich mag Fehlerstring zu diesem Fehler setzen. Aber dann brauche ich einen als auch Rückgabewert. Rat?

Answer 1

Speichern Sie Ihre Rückgabewert in einer temporären Variablen wie folgt aus:

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 der catch-Block heben / werfen und es 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 die Syntaxfehler, ich bin ein bisschen rostig auf C #

.

Answer 3

Sie sollten die Anrufer mit einem Try-Catch wickeln ... irgendwelche Ausnahmen, die in der Routine vorkommen, dass perlt aus dem Anrufer genannt wird und Sie können sie dort fangen.

Ich persönlich denke, es ist viel des Guten einen Versuch fangen in dieser Routine zu haben, ist, wie Sie den Anrufer sollte die Ausnahmebehandlung.

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

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

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

    // logic here
    return dt;
}

Answer 4

Die Variable error sieht verdächtig nach einem Fehlercode Variable. Empfohlene Praxis ist Ausnahmen zu verwenden Fehlerinformationen direkt weitergeben, soweit erforderlich, anstatt die Dinge aus in Fehlercodes zu speichern.

Sie tun effektiv die gleiche Sache mit Ihrem error wie würden Sie, wenn Sie nur die Ausnahme von der Anrufer aufgefangen werden lassen: die Verantwortung des Entfernens von dem Verfahren auf einen Fehler reagiert selbst. Dies ist ein gutes Ziel zu haben. Aber die Verwendung eines Fehler Zeichenfolge nicht gewinnen Sie nichts über die Verwendung einer Ausnahme. In der Tat, verlieren Sie Informationen auf diese Weise. Es gibt eine beliebige Anzahl von Arten von Fehlern, die auftreten könnten, und viele haben besondere Ausnahmen mit ihnen verbunden ist, mit ihren eigenen speziellen Eigenschaften kontextuelle Informationen über den Fehler zu halten. Mit nur die Nachricht in einem String zu speichern aus, Sie verlieren diese Informationen.

Also, wenn Ihr Ziel ist insbesondere die Art des Fehlers zu verbergen ist, die von dem Anrufer auftreten, können Sie nur durch, indem man die Ausnahme gewinnen.

Eine andere Sache zu prüfen ist, ob dies wirklich ein Fehler Szenario. Wenn ja, dann ist es sehr unwahrscheinlich, dass Ihr Rufmethode überhaupt interessieren wird, was ist der Rückgabewert. In diesem Fall haben Sie nichts zu befürchten von nur lassen die Ausnahme gehen und nichts zurück. Wenn es nicht wirklich ein Fehler Szenario ist, und der Anrufer wird einfach weiter fortsetzen und noch etwas anderes tun, na ja, das ist für den Anrufer zu entscheiden, nicht wahr? Es gibt noch nicht viel Nutzen durch Rückgabe eines Fehlerfolge und eine Dummy-Datentabelle oder eine Null, über werfen die Ausnahme mit all ihren kontextuellen Scheitern info zu erhalten.

Answer 5

Wenn Sie vorhaben, die mit dem Hinterkopf „keine Ausnahme Weg werfen“ (was ich nicht unbedingt reccomending), könnten Sie den TryParse Ansatz folgen MS verwendet.

So 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 6

Es hängt von Ihnen Anwendung. Sie können null zurückkehren, wird ein leeres DataTable oder was auch immer unter Umständen geeignet ist.

Answer 7

ich würde annehmen, dass Sie nach wie vor die Nachricht einstellen, dann wieder null 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

Da Sie die Ausnahme sind cacthing (und es nicht erneut zu werfen) in Ihrem Beispiel Der Außen Code geht davon aus every in Ordnung ist und daher sollten Sie etwas Nützliches zurück.

Wenn Sie dort die Ausnahme zu fangen und somthing zu tun, das alles in Ordnung ist, aber wenn es noch ein Fehlerfall ist, sollten Sie es auch werfen, oder eine andere Ausnahme, vielleicht mit dem man nur als Innerexception gefangen.

Answer 10

Ich denke, Ihr Code auf einem ausreichend hohen Niveau des Stapels Aufruf ausgeführt wird, und es ist mit UI-Code vermischt. Wenn dies wirklich der Fall ist, könnten Sie im catch-Block return null. Wenn Sie jedoch wieder verwendbaren Code schreiben, sollten Sie es Refactoring, so dass es nicht UI Manipulation enthält und die Ausnahme auf einem höheren Niveau in den Call-Stack behandeln.

Answer 11

Sie können darunter wie der 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;
      }

}