Rückgabewerte und Fehlerbehandlung allgemein bzw. am Beispiel

[Daniel Thoma]

Hallo Martin,

also eher das konsequente Schema
  Ergebnis = Funktion(Argumentliste)
im mathematischen Sinn einer Funktion?

Ja, meinetwegen auch noch (Ergebnisliste) = Funktion(Argumentliste) im Sinne einer vektorwertigen Funktion. Mag daran liegen, dass ich z.Z. öfter Programme schreibe, die auf einem mathematischen Modell aufsetzen. Und wenn man das erstmal so durchdacht hat, kann man es auch sehr bequem so implementieren.

Das ist deine Meinung, die sollst du bitte auch haben - ich finde, wie gesagt, die andere Variante leichter nachzuvollziehen.

Evtl. liegt es natürlich daran, was man nachvollziehen will. Will man die Logik des Programms verstehen oder wie es technisch abgearbeitet wird. Ich gehöre zu den Leuten, die am liebsten nur ein abstraktes Modell in den Compiler füttern würden, um ein Programm zu erzeugen. Funktionale Programmiersprachen kommen an sowas teilweise recht na dran.
Natürlich ist es wichtig, auch zu wissen, was da passiert bis auf die unterste Ebene, aber um dann ein Programm zu schreiben, muss ich mir das zumindest nicht für jede Zeile überlegen ;-)

Hochsprachen wie Pascal und C habe ich erst sehr viel später gelernt, sehe aber in Gedanken immer noch in etwa den Maschinencode, der meinen C-Anweisungen entspricht.

Ja, bei diesen Sprachen geht das noch, bei Java o.ä. geht es schon weniger. Bei funktionalen oder gar logischen Sprachen funktioniert es praktisch gar nicht mehr, weil man nicht einmal mehr so genau weiß, wann was berechnet wird, manche Sprachen und Compiler können auch automatisch parallelisieren, da weiß man dann noch nicht mal unbedingt, was so alles gleichzeitig passiert. Man kann natürlich gegen so etwas sein, weil man gerne jedes Detail kontrolliert. Abstrakter zu denken und zu programmieren ermöglicht aber eben einfach, komplexere Dinge zu beherrschen bzw. weniger Zeit dafür zu brauchen. Jedenfalls, wenn man mit der Abstraktion klar kommt, was zumindest beim funktionalen und logischen Kram auch nicht jede Manns Sache ist ;-)

Kann man? Man weiß nur, *dass* irgendwo im try-Block ein Fehler aufgetreten ist, aber nicht genau wo und warum.

Ich meinte den Fall, dass es gar keinen try-Block gibt. Da wird eben nicht weiter gearbeitet, sondern das Programm gleich an der Fehlerstelle abgebrochen (und nicht da, wo es vielleicht mal irgendwo dann kracht als Resultat). Wenn man einen try-Block verwendet, weiß man zugegebenermaßen nicht genau, an welcher Stelle der Fehler auftritt. Da gibt es dann mehrere Fälle: Entweder muss man es gar nicht wissen, man weiß es, weil die Exception deklariert werden muss und der Compiler einem die Stellen sagt, man weiß es, weil es dokumentiert ist (ok Theorie ;-) oder man weiß es, weil man den Fehler gleich so lokal abfängt, wie nötig ist.
Ehrlich gesagt ist das normalerweise kein Problem.

Mir ist übrigens noch ein Beispiel eingefallen, dass ohne einen Exception-Mechanismus fast gar nicht lösbar ist:
Das durchreichen von Fehlern, die praktisch überall auftreten können und lokal nicht verarbeitbar sind.
Beispiel: Stack oder Heap voll. Diese Fehler können praktisch überall auftreten, dennoch will man sie sicher nicht überall per Rückgabewert signalisieren, da man sonst den Rückgabewert für nichts anderes mehr nutzt. Es kann aber durchaus sinnvoll sein, so einen Fehler abzufangen, beispielsweise in einem Serverprogramm. Sollte der beim Abarbeiten einer Aufgabe in eine Endlosrekursion laufen oder der Speicher ausgehen, gibt es keinen Grund nicht einfach die Aufgabe zu verwerfen und so weiter zu arbeiten. Es lassen sich da sicher noch andere Beispiele finden.

Natürlich muss ich dann (vermutlich) aus dem normalen Ablauf ausbrechen. Ich meinte aber eigentlich das Lesen und Nachvollziehen des Programmcodes, nicht das Ausführen.

Klar ich auch. Du musst das ja Programmieren und Nachvollziehen, aber in diesem Punkt werden wir uns wohl kaum einigen ;-)

Grüße

Daniel