Laden...

Rückgabe von Methoden: Ergebnis, falls erfolgreich, Fehler sonst. Wie am besten?

Erstellt von reloop vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.519 Views
Thema geschlossen
reloop Themenstarter:in
139 Beiträge seit 2010
vor 13 Jahren
Rückgabe von Methoden: Ergebnis, falls erfolgreich, Fehler sonst. Wie am besten?

Hallo,

ich habe folgendes Problem - bzw. eher Frage.

Wie realisiert ihr bei euren Anwendung die Rückmeldung der Funktionen?

Angenommen, ich habe eine Form, diese Ruft eine Funktion aus meiner DLL auf, die irgendetwas prüft (Korrektur der Daten oder sonstiges).

Diese rufe ich dann auf mit myFunction().

Wenn diese Funktion jetzt fehlerfrei durchlaufen wurde, soll die Verarbeitung weiterlaufen. Wenn jedoch ein Fehler aufgetreten ist, würde ich gerne dass die Funktion ein Array mit Daten zurückliefer, wo drin stand, was evtl. schief lief etc.

Nun würde ich gerne einfach mal wissen, wie Ihr in diesem Fall reagiert / agiert.

Sprich, wie eure Rückmeldungen aus Functionen aussieht, die ihr in eure Programme einbindet.

Ich hoffe mein Anliegen ist nachvollziehbar.

Danke für eure Hilfe,

Gruß,

cs.

4.221 Beiträge seit 2005
vor 13 Jahren

Kommt auf die Härte des Fehlers an

Wenn ein Problem erwartet wird, dann z.B: mit einem bool....

Ansonsten Exception werfen.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

reloop Themenstarter:in
139 Beiträge seit 2010
vor 13 Jahren

Bedeutet im Umkehrschluss aber, dass meine Funktionen alle in einem Try aufgerufen werden, richtig?

Und hättest du evtl. kurz ein Beispiel wie das aussehen würde?


public Exception CheckData()
{
   if "alles richtig, dann arbetie weiter"

   else 
      "fülle meine exception mit meinem rückgabe array" o.ä.

}

Beste Grüße & Danke für die Hilfe,

cs.

4.221 Beiträge seit 2005
vor 13 Jahren

Bedeutet im Umkehrschluss aber, dass meine Funktionen alle in einem Try aufgerufen werden, richtig?

Jein 😃

Ich mache es normalerweise so:

Wenn ich bei einem Fehler in einer Funktion trotzdem weitermachen kann, dann bevorzuge ich die bool-Lösung.

Wenn der Zustand so undefinierbar ist, dass die folgenden Funktionen entweder ebenfalls einen Fehler auslösen würden... oder noch schlimmer aufgrund des undefinierten Zustandes Amok laufen würden dann bevorzuge ich die Exception-Lösung.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

6.862 Beiträge seit 2003
vor 13 Jahren

Hallo,

keinesfalls Exception als Rückgabewert. Die wirft man im Code und von außerhalb fängt man sie wie du richtig erkannt hast, mit try ab.

Aber da der Rückgabewert anscheinend ja nicht gebraucht wird zur Rückgabe von Daten (sonst hättest du ja net den mit ner Exception benutzen wollen, könntest du dir auch einfach ne Statusklasse schreiben die nen Property für den Status hat, der z.B. Erfolgreich / nicht Erfolgreich sein könnte, und weitere Properties um einen evtl. Fehler näher zu beschreiben. Und dann nen Objekt dieser Klasse als Rückgabewert benutzen.

Baka wa shinanakya naoranai.

Mein XING Profil.

reloop Themenstarter:in
139 Beiträge seit 2010
vor 13 Jahren

Klasse, das mit der Statusklasse werde ich so umsetzten. Danke für den Hinweis!

5.941 Beiträge seit 2005
vor 13 Jahren

Hallo zusammen

Programmierhans meinte damit sicherlich folgendes:

  • Wenn du einen Fehler behandeln kannst, sodass das Programm in einem definiertem Zustand weiterlaufen kann, passts.

Dann könntest du ggf. ein Boolean zurückgeben, wenn du einen bestimmten Status brauchst, bspw. um nach einer Pause erneut einen Versuch zu starten (Netzwerkverbindung, I/O, etc...).

Exception meinte er sicherlich nicht als Rückgabewerden, sondern eine Exception werfen.

Auffangen?

Nur, wenn man die Exception im äusseren Kontext so behandeln kann - wie oben beschrieben - dass das Programm in einem konsistenten Zustand weiterlaufen kann.

Statusklassen und ErrorCodes würde ich mit Vorsicht anschauen und benutzen, meistens gibt es bessere Möglichkeiten.

Ein Real-World-Beispiel für eine "Exception" die geworfen, aber nicht aufgefangen wird, weil die Software sonst "Amok" läuft, heisst, der Zustand inkonsistent wird (zum dritten Mal):

  • Windows Bluescreen 😃

Wenn der BSOD nicht kommt, kann Windows ohne Probleme weiterlaufen, und das heisst einiges. Da ich seit W7 einen Bluescreen hatte, der allerdings mit einem Hardwareproblem zusammengehangen hat.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

reloop Themenstarter:in
139 Beiträge seit 2010
vor 13 Jahren

Also mir geht es da um folgendes:

Ich erzeuge aus meiner Form heraus (über eine DLL) eine XML Datei und lese diese auch aus.

Angenommen ich rufe aus meiner Form jetzt die Funktion auf:

readXML()

möchte ich, dass das programm einfach weiterläuft, wenn die Funktion erfolgreich verarbeitet wurde, jedoch wenn die Datei z.b. nicht existiert, mein readXML ein Array zurückggibt, mit dem Status = false und evtl einer Meldung = "Die XML Datei ist nicht vorhanden."

Die Statusklasse wäre also in ihrem simpelsten Zustand:

    public class ReturnStatus
    {
        public ReturnStatus()
        {
            Status = true;
        }

        public bool Status { get; set; }
        public string Meldung { get; set; }
    }

Was hältst du von dieser Variante?

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo cs.,

bitte beachte [Hinweis] Wie poste ich richtig? Punkt 1.1.1. Jedes (gute) C# Buch beschreibt auch die Gründzüge der Ausnahmebehandlung. Die sind dir offenbar noch unbekannt. Lies dich also bitte erstmal selbst in das Thema ein.

EDIT: Auch im Forum wurde das Thema schon öfter besprochen. Bitte benutze die Forumssuche.

Siehe zum Beispiel:

Best Practice: Exceptions
Für jeden Fehler eine eigene Exception?

herbivore

Thema geschlossen