hotti: Warum eigentlich Exceptions?

hi, schöner Tach ;)

s. Thema, Vorschlag: Alle Funktionen/Methoden geben false zurück, wenn im Verlauf keine solchen Fehler aufgetreten sind, die es Wert gewesen wären, eine Exception zu werfen.

Wenn es einen Fehler gibt, der eine Exception Wert ist (Datei nicht gefunden, keine DB-Verbindung..., weitere Verarbeitung nicht sinnvoll) macht die Methode ein return('Fehler: x,y'); und beim Aufruf wird nur noch abgefragt, ob es einen Fehler gab. Das Gefummel mit try/catch und getMessage() entfällt, der Fehlertext steht ja als Klartext im ReturnCode.

Macht das jemand von Euch auch, wenn ja, warum nicht?

Hotti

  1. Hallo,

    s. Thema, Vorschlag: Alle Funktionen/Methoden geben false zurück, wenn im Verlauf keine solchen Fehler aufgetreten sind, die es Wert gewesen wären, eine Exception zu werfen.

    Was ist mit methoden deren Aufgabe ist einen String oder ein Objekt oder gar ein Boolean zurückzugeben wie zum Beispiel user.getName()?

    Jeena

    1. hi,

      s. Thema, Vorschlag: Alle Funktionen/Methoden geben false zurück, wenn im Verlauf keine solchen Fehler aufgetreten sind, die es Wert gewesen wären, eine Exception zu werfen.
      Was ist mit methoden deren Aufgabe ist einen String oder ein Objekt oder gar ein Boolean zurückzugeben wie zum Beispiel user.getName()?

      Gute Frage ;)
      Was ich wiedermal (unabsichtlich) nicht geschrieben habe: Die Methoden, um die es mir hier geht, stehen im Programmablauf ganz am Ende, da geht das auf diese Art und Weise.

      Es ist ja im Prinzip nichts Neues, Programme geben ans OS auch eine 0, wenn kein Fehler aufgetreten ist ;)

      Viele Grüße,
      Hotti

  2. Hi,

    Macht das jemand von Euch auch, wenn ja, warum nicht?

    Weil das gegenüber echten Exceptions den gravierenden Nachteil hat, dass man auf den Rückgabewert an Ort und Stelle reagieren, bzw. ihn nach oben „durchreichen“ müsste.

    MfG ChrisB

    --
    RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
    1. hi,

      Macht das jemand von Euch auch, wenn ja, warum nicht?

      Weil das gegenüber echten Exceptions den gravierenden Nachteil hat, dass man auf den Rückgabewert an Ort und Stelle reagieren, bzw. ihn nach oben „durchreichen“ müsste.

      Jow, das isses, danke Dir!!!

      Viele Grüße,
      Hotti

      1. Hello,

        Macht das jemand von Euch auch, wenn ja, warum nicht?

        Weil das gegenüber echten Exceptions den gravierenden Nachteil hat, dass man auf den Rückgabewert an Ort und Stelle reagieren, bzw. ihn nach oben „durchreichen“ müsste.

        Jow, das isses, danke Dir!!!

        Nee, das isses nicht wirklich und schon gar nicht vollständig.

        Schon in den frühen Hochsprachen im Real Mode, ja sogar schon in Makroassemblern hat man mit "runtime-errors" gearbeitet. Dies war im Prinzip ein Stückchen Code, das bei kritischen Operationen von der IDE (der Makroassembler Entwicklungsumgebung) automatisch in den eigentlichen Code eingefügt wurde und so z.B. Variablenüberlauf, Filesystemfehler, Rechenfehler (Division durch 0), usw. abgefangen hat. Es hat aber (anfangs) immer nur auf die Exit-Routine des Programmes verzweigt, in der dann zumindest die wichtigsten Dinge noch aufgeräumt werden konnten (Speicher freigeben, Dateien schließen usw.) und eine spärliche Fehlermeldung ausgegeben werden konnte.

        Das hatte den Sinn, dass nach einem Absturz des Programmes nicht der ganze Rechner stand.

        Erst mit der OOP (auch schon der anfänglichen zu Assemblerzeiten) hat man dann versucht, speziellere globale Reaktionen einzuführen. Leider fehlten da am Anfang noch die passenden Entwicklungsumgebungen, die einem die geführte Codeentwicklung ermöglicht haben. Man musste alle denkbaren Fehler noch "zu Fuß" einfangen und klassifizieren und dafür den Alternativcode im Fehlerfalle erstellen. Viel schlimmer war aber das händische Auflösen der Ausprungadresse, der Zieladresse für die Fehlerbehandlung und der Rücksspungadresse im Fehlerbehebungs-Erfolgsfall sowie deren Beseitigung nebst Beseitigung des zugehörigen Codeblockes im Fehlerbebungs-Misserfolgsfall.

        Dies wird duch das "try-catch"-Prinzip durch die IDEs nun eher wewniger als mehr automatisch erfüllt, denn man muss ja dafür diese lästigen Zeilen vorsehen. Der ganze Apparat dahinter wird aber dann von der IDE (und ihren Helfern) eingepflegt.

        Zusätzlich dazu verzweigen die angemeldeten Fehleraktoren nicht statisch auf einen Code, sondern über eine Translationsschicht (ähnlich der guten alten IVT), sind also "umbiegbar", damit also in eine Meldungsschlange umleitbar.

        Das Wesentliche dabei ist, dass durch das neue Konzept auch Daten (Parameter) übermittelt werden können, was bei simplen Runtime-Errors nicht möglich war. Da stand dioe Begründung dann im globalen Environment.

        So, nun warte ich auf diejenigen, die es anhand von Codeausschnitten alles viiiiel besser erklären können [...] :-)

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
         ☻_
        /▌
        / \ Nur selber lernen macht schlau
        http://bergpost.annerschbarrich.de
        1. hello,

          Macht das jemand von Euch auch, wenn ja, warum nicht?

          Weil das gegenüber echten Exceptions den gravierenden Nachteil hat, dass man auf den Rückgabewert an Ort und Stelle reagieren, bzw. ihn nach oben „durchreichen“ müsste.

          Jow, das isses, danke Dir!!!

          Nee, das isses nicht wirklich und schon gar nicht vollständig.

          Doch, das isses. Wenn schon mit Exceptions arbeiten, dann richtig, ChrisB hat Recht ;)

          Return 'Fehlermeldung', schön und gut, aber es müsste eine Extra-Wurst für solche Funktionen gebraten werden (gegrillt wird nachher, erst die Arbeit!):

          Exceptions: Alles, was eine Ex werfen kann, kommt in den try{} Block. Wenn irgendwo eine Ex auftritt, hält das Script an, das ist in PHP genauso wie in Perl.

          Beispiel:

            
          function response($cfg = array()){  
          	# aus REQUEST_URI wird URL bestimmt  
          	$url = '/'; # fake  
            
          	try{  
          		$class = $cfg[$url]['class'];  
          		$ro = new $class ($cfg, $url);  
          		if($ro->param()){$ro->control();}  
          		else{$ro->browse();}  
          		echo $ro->start_html(), $ro->bodybuild();  
          	}  
          	catch (Exception $e) {  
          		header("HTTP/1.1: 404 Not Found");  
          		header("Content-Type: text/plain; charset=UTF-8");  
          		echo $e->getMessage(), "\n";  
          	}  
          }  
          
          

          Hotti

          1. Hello,

            Jow, das isses, danke Dir!!!

            Nee, das isses nicht wirklich und schon gar nicht vollständig.

            Doch, das isses. Wenn schon mit Exceptions arbeiten, dann richtig, ChrisB hat Recht ;)

            Exception:
              Du hast mich falsch verstanden
              Rücksetzen der Fehlerpuffer
              Rücksetzen des Verständniszählers
              Übergabe von neuen (zusätzlichen Parametern)
                Du hast den Text nicht gelesen. Der behandelte nicht nur
                "ganz oder gar nicht" sondern das Warum dahinter.
              Wiedereintritt ins Programm mit Exception-Counter = 1 vor der Exception

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
             ☻_
            /▌
            / \ Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
            1. hi lieber Tom,

              Exception:
                Du hast mich falsch verstanden

              Ja, das kann sein, ich verstehe nicht wirklich, was Du mir sagen möchtest. Bei meinen Webanwendungen gibt es keinen 'Wiedereintritt ins Programm' noch werden Exceptions gezählt, wenn Ex'ns auftreten werden meine Programme mit einem definierten Zustand beendet, sofern es Webanwendungen sind.

              Anders ist es bei meinen Daemons, die ich in letzter Zeit geschrieben habe, bei denen ist das Programm nicht zuende: Tritt hier eine Ex auf, fällt der D in eine Warteschleife in welcher er prüft, ob 'mögliche Gründe' für die Ex noch bestehen, wenn nicht => Wiedereintritt in den geplanten Programmablauf.

              Feierabend ;)

        2. Hallo Tom,

          Erst mit der OOP [...]

          Du scheinst dem guten alten Cato nachzueifern :-)

          Freundliche Grüße

          Vinzenz

          1. Hello Vinzenz,

            Erst mit der OOP [...]

            ... und bitte weiterlesen.

            Du scheinst dem guten alten Cato nachzueifern :-)

            Wie meisnt Du das? Meinst Du, dass ich das Abfackeln der Paradigmen der OOP beantrage? Das wäre dann eine geklitterte (halbe) Wahrheit.

            Ich finde diverse Denkansätze und Tools in den IDEs für OOP sehr hilfreich, ich finde nur, dass sich die OOP von der Bindung an C und deren Unzulänglichkeiten endlich mal trennen müsste. Aber das habe ich ja mit meinem vorangegangenen Posting hier noch gar nicht erwähnt.

            OOP bedeutet doch nicht, dass man ständig Code, Daten und Semantik im Human-Readable-Source-Code mischen muss.

            Reicht doch, wenn der Prozessor das nachher so im Opcode zur Verdauung bekommt, oder?

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
             ☻_
            /▌
            / \ Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
  3. hi, schöner Tach ;)

    s. Thema, Vorschlag: Alle Funktionen/Methoden geben false zurück, wenn im Verlauf keine solchen Fehler aufgetreten sind, die es Wert gewesen wären, eine Exception zu werfen.

    Wenn es einen Fehler gibt, der eine Exception Wert ist (Datei nicht gefunden, keine DB-Verbindung..., weitere Verarbeitung nicht sinnvoll) macht die Methode ein return('Fehler: x,y');

    Ja, warum nicht? Naja, dann muss man selbst immer if Abfragen schreiben, ob die Rückgabe ein Fehler ist und wenn ja ihn behandeln und ggf. durchreichen. Wobei, das könnte man auch automatisieren und den Fehler einfach durchreichen lassen, ohne dass der Programmierer viel extra Aufwand hat. Nur, woher weiß man, ob dieser String nun wirklich einen Fehler darstellt oder ob es nicht z.B. nur ein ganz normaler Text ist, den der User eingegeben hat?
    Hey, ich hab ne Idee, lass uns doch anstelle eines Strings eine neue Klasse machen, die wir "Exception" nennen und die dann auch einen Fehler String haben kann, wobei der Compiler und die IDE aber sofort erkennen, dass das ein Fehler ist. Oh das gibts schon? Na dann kann ich mir den Weg zum Patentamt ja sparen...

    1. Hello,

      [...] das könnte man auch automatisieren und den Fehler einfach durchreichen lassen, ohne dass der Programmierer viel extra Aufwand hat. Nur, woher weiß man, ob dieser String nun wirklich einen Fehler darstellt oder ob es nicht z.B. nur ein ganz normaler Text ist

      Eben, indem man einen Fehlerpuffer mit eineindeutiger Fehlernummer immer durchreicht. Jede Prozedur/Funktion kann selbst bestimmen, ob sie nur eine Fehlernummer 0 zulässt, um selber tätig zu werden, oder ob sie auch mit einer Fehlernummer > 0 noch eigene Behandlungsszenarien kennt.

      Das ist die Frühform des error-messaging gewesen, die schon eine erhebliche Verbesserung (und leider auch Verkomplizierung für den Programmierer) der Programmraktionen für den Anwender gebracht hat.

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
       ☻_
      /▌
      / \ Nur selber lernen macht schlau
      http://bergpost.annerschbarrich.de
    2. hi,

      Hey, ich hab ne Idee, lass uns doch anstelle eines Strings eine neue Klasse machen, die wir "Exception" nennen und die dann auch einen Fehler String haben kann, wobei der Compiler und die IDE aber sofort erkennen, dass das ein Fehler ist. Oh das gibts schon? Na dann kann ich mir den Weg zum Patentamt ja sparen...

      Genau! Warum das Rad neu erfinden? Lasset uns Raketen bauen!

      Hotti

      --
      Warum wegen drei Bratwürsten den Grill anschmeißen? Die brat ich doch gleich mit der Heißluftpistole!
  4. Hello,

    da das "humoristische" Posting von "Orgasma de Luxe" schon verschwunden ist, möchte ich den durchaus überlegenswerten Tenor nochmals aufgreifen.

    "Orgasma de Luxe" provozierte auf Hottis Posting:

    Das Gefummel mit try/catch und getMessage() entfällt...

    sieht dann aber nicht so professionell aus. Was meinst du, warum immer noch verbohrte Zeitgenossen an Java glauben?

    Ich möchte durchaus meine Gedanken dazu äußern:

    Auch wenn Du vielleicht ganz viel Ironie in Dein Posting gelegt hast, ist es mMn stumpf geradeaus betrachtet gar nicht so falsch.

    Das Konzept wird für den Programmierer leider langsam auch sehr unübersichtlich. Er kann in keiner Weise mehr erahnen, warum da was im Hintergrund geschieht, es sei denn, er hat die letzten 20 bis 30 Jahre daran mitentwickelt.

    Das kann nicht der Sinn einer Hochsprache sein!

    Liebe Grüße aus dem schönen Oberharz

    Tom vom Berg

    --
     ☻_
    /▌
    / \ Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de
    1. hi lieber Tom,

      Das kann nicht der Sinn einer Hochsprache sein!

      Schlimmer: Bis vor wenigen Tagen und zum Teil bis in den heutigen Abend hinein, war ich der Meinung, dass es mit PHP gar nicht möglich ist, professionell zu programmieren.

      Aber was heißt eigentlich professionell? Richtig: Das Werkstück mit dem dazu passenden Werkzeug bearbeiten. Und je mehr ich mich in PHP fit mache, umso mehr sehe ich, das auch PHP die passenden Werkzeuge hat und ich lerne, damit umzugehen.

      Mein persönliches Ziel ist es, ein Framework in PHP so zu bauen, wie ich das mit Perl gemacht habe und dass diese beiden Frameworks voll kompatibel über einunddieselbe Konfigurationsdatei lauffähig sind. Genauso wie in meinem Perl-Framework wird eine neue Anwendung im PHP-FW eine neue Klasse sein, die beliebigen Content ausgeben kann wozu in einer Datei lediglich zwei oder drei Methoden zu schreiben sind (Inherit, Overload). Umschalten von einem FW zum Anderen heißt dann nur noch, in der Serverkonfiguration einen anderen Rewrite-Handler einzutragen (PHP vs. Perl) und das Ergebnis sieht ganz genauso aus.

      Vorasussichtlich habe ich das morgen (äh heute) abend fertig ;)

      Schönen Sonntag!

  5. Macht das jemand von Euch auch, wenn ja, warum nicht?

    Das ist ja Fehlerbehandlung wie in C. Dieses Modell ist überholt. Kann man herrlich in PHP (Standardbibliothek, etlicher 3rd-Party-Code) sehen, wozu das führt: weil der eine Funktion/Biblithek etc. konsumierende Programmierer nicht gezwungen wird, Fehler zu behandeln, lässt er es, und erzeugt dadurch kaputten Code.

    Warum eigentlich Exceptions?

    *Eigentlich* solltest du das als Programmierer schon wissen. In abstrahierten, mittelgroßen Systemen kann man gar nicht gut die Fehler an der originären Stelle behandeln. Ich kaue dir nicht die Geschichte der letzten dreißig Jahre vor, mach dich selbst schlau:
    • Kapitel 14 in PBP
    Advantages of Using Exception Handling

    PS: Wenn deine Frameworks nicht Exceptions unterstützen, würdige ich sie keinen zweiten Blicks; mit dieser Ansicht stehe ich nicht allein. Uns ist die Zeit zu schade, wie Anno Tobak zu programmieren.

    1. Hi,

      PS: Wenn deine Frameworks nicht Exceptions unterstützen, würdige ich sie keinen zweiten Blicks; mit dieser Ansicht stehe ich nicht allein. Uns ist die Zeit zu schade, wie Anno Tobak zu programmieren.

      PHP
      Exception

      Perl
      Exception
      Perl
      Exception

      U.v.a.m. mache ich mit Exceptions ;)

      Hotti

      PS: Das PHP-Framework, erster Link, habe ich übers Wochenende geschrieben. War nur Tipparbeit, der Aufbau ist wie mein Perl-Framework und die Konfigurationsdateien sind voll kompatibel.

      1. Hi,

        PS: Wenn deine Frameworks nicht Exceptions unterstützen, würdige ich sie keinen zweiten Blicks; mit dieser Ansicht stehe ich nicht allein. Uns ist die Zeit zu schade, wie Anno Tobak zu programmieren.

        PHP
        Exception

        Perl
        Exception
        Perl
        Exception

        U.v.a.m. mache ich mit Exceptions ;)

        Hotti

        PS: Das PHP-Framework, erster Link, habe ich übers Wochenende geschrieben. War nur Tipparbeit, der Aufbau ist wie mein Perl-Framework und die Konfigurationsdateien sind voll kompatibel.

        Und der Manager, über den jeder Request gehandelt wird (Rewrite), wirft selbstverständlich auch eine Exception mit dem HTTP-Status: 404 Not Found ;)

        Meine Frage war zugegebenermaßen einwenig provokativ: Ich kenne ein paar Programmierer, die machen das nurso (return 0 vs. Fehlercode), die sind allesamt viel jünger als ich und wundern sich, dass sie beim Programmieren nicht so recht vorwärts kommen ;)

        Es lebe das Handwerk des Programierens!

        Horst Schreiner

        --
        Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
  6. Moin Hotti,

    Weil das die einzige Möglichkeit ist im Konstruktor einen zwingenden Fehler zu werfen. Stell dir mal eine Klasse vor die einen Schüler verwaltet. Zwingend für diesen SchülerHandler ist das Objekt Schüler. Dieses wird im Konstruktor übergeben (und nur da, weil die Klasse SchülerHandler ohne einen Schüler nicht arbeiten kann). Im Konstruktor wird dann geguckt wie alt der "angebliche" Schüler ist. Da erkennt die SchülerHandler Klasse Moment mal das ist ja gar kein Schüler, weil der Schüler seit 2 Wochen seinen Abschluss hat. Um das zu prüfen musst du entweder nach dem Initialisieren immer zwingend eine Methode aufrufen oder du machst es direkt im Konstruktor. Im Konstruktor hast du aber nur die Möglichkeit einer Exception, um den Fehler nach außen zu bringen.

    Ich verwende Exceptions relativ sparsam. Meistens nur um das Programm ab zu brechen. Exceptions behandle ich eigentlich nie. Dass erledigt eine schöne php Funktion, welche die Exceptions die nicht gefangen wurde automatisch behandelt. Dann wird eine 404 Seite angezeigt. Zudem wird die Exception gespeichert.

    Man muss jedoch auch sagen was man programmiert. Ich bin (leider) nur mit Webseiten am rumbasteln. Da spielt es keine Rolle wenn mal was schief läuft. Wenn du z.B. statt 10 Kommentare nur 9 siehst ist das in der Regel total egal. Deswegen den Code mit Exceptions aufblähen ist quatsch. Jemand der hingegen Online Banking programmiert wo eine Falsche Buchung im schlimmsten Fall zu einem Millionenschaden führt sollte das ganze System "Fehlerfrei" bekommen. Aber seien wir mal ganz ehrlich, der wird auch besser Bezahlt, bekommt mehr Zeit zum programmieren, mit einem kurzen Satz - lohnt sich da die Fehlerbehandlung.

    Gruß
    unterbezahlter
    T-Rex