Rückgabewerte und Fehlerbehandlung allgemein bzw. am Beispiel

[Der Martin]

Moin Daniel,

Du hast sowieso eine etwas ungewöhnliche Programmierphilosophie, ich schiebe das mal auf zu viel Assembler ;-)

ach, nur kein Neid! Ich weiß, Assembler ist quasi das Reinheitsideal der Programmierung. :-)

b) oder grundsätzlich nur einen Statuscode zurückgeben (in der Regel 0 für erfolgreiche Ausführung), und ihre "Nutzlast" über Argumente, die als Referenz übergeben werden.
Bei b) verwendest Du also keine Funktionen im eigentlichen Sinne. Bei solchen "Prozeduren" hat man z.B. auch nicht mehr die Möglichkeit, sie direkt ineinander einzusetzen.

Ja, das stimmt natürlich. Das muss man beim Design berücksichtigen. Oft ist dieses Ineinander-Einsetzen aber vom Ablauf her sowieso nicht sinnvoll. Wenn doch, schmeißt man sich natürlich Knüppel zwischen die Beine, wenn man sich das selbst vereitelt.

Du scheinst einen recht wenige funktionalen Programmierstil zu pflegen.

Im Gegenteil. Wo immer ich die Möglichkeit sehe, ein Häufchen thematisch abgeschlossenen Code in eine Funktion auszulagern, dann tu ich das - außer wenn ich dieses Stück Programmcode dann wieder nur einmal nutze. In diesem Fall lasse ich's lieber inline.

Das muss man im Prinzip sowieso. Ob man eine Handvoll Exceptions bastelt oder ein Funktionsergebnis auf ein paar konkrete Werte abprüft, läuft ungefähr auf dasselbe hinaus.
Man muss aber die eigentliche Berechnung nicht durch Fehlerbehandlung "verschmutzen".

Die eingestreuten try...catch-Blöcke empfindest du nicht als Verschmutzung?

Ein Fehler führt zum Ausbruch aus dem normalen Ablauf und man kann den Fehler direkt behandeln.

Ja, und die Fehlerbehandlung findet (im Programmcode) woanders statt als der reguläre Ablauf. Deswegen sagte ich, ich finde das Konzept unübersichtlich und manchmal schwer zu verfolgen.

Zudem ist es eben einfach Fehlerbehandlung weiter zu reichen.

Ja, eben:

~~~ function DoThis(blah, blubb, blaeh)
   { DoSomethingWith(blaeh);
     return (DoThat(blah+1, blubb));
   }

  
Da ist die Fehlerbehandlung doch wunderbar weitergereicht. Andernfalls macht man eben sowas:  
  
  ~~~
if (error=FunctionThatMightFail())  
   { // z.B. Aufruf einer zentralen Fehlerbehandlung  
     // oder Abfrage mit switch (error)  
   }  
  // weiter im normalen Programmfluss

Bei Rückgabewerten hat jede Funktion ihre eigene Fehler-Konvention.

Dann ist das Gesamtkonzept schlecht durchdacht. Wenn ich Module schreibe, die die Gesamtheit der Funktionalität zu einem bestimmten Thema bündeln, dann verende ich auch im ganzen Modul einheitliche Bezeichner, Fehlercodes und Aufrufkonventionen.

Ich hab durchaus auch schon in Sprachen bzw mit Bibliotheken programmiert, wo das so gehandhabt wird. Oft führt das sogar dazu, dass der Fehlerrückgabewert einfach ignoriert und mit diesen Daten dann irgendwie weitergearbeitet wird.

Das sollte man natürlich vermeiden - oder man muss *ganz genau* wissen, was man tut.

Was machst Du, wenn Du eine in einem Programm lesen musst, aber das nicht kannst? Musst Du da nicht aus dem regulären Kontrollfluss ausbrechen?

Keine Ahnung - diesem Satz fehlt anscheindend etwas. Ich verstehe ihn nicht. ;-)

Man muss diesen natürlich immer noch selbst weiterreichen und vermischt normalen mit Fehlerkontrollfluss. Programme dieser Art finde ich eigentlich meist umständlicher als nötig.

Ansichtssache. Ich finde es durchaus hilfreich, alle Kontrollflusspfade - den normalen wie auch den Fehlerfall - direkt zu sehen.

Schönes Wochenende noch,
 Martin