Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Rückgabewerte und wie auf Fehler reagieren

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    1. solltest Du das nicht statisch machen
    2. solltest Du PHP5-gerecht arbeiten und Sichtbarkeiten definieren
    3.
    versuch ich die beiden Funktionen nacheinander mit zu prüfen und im Fehlerfall schmeiße ich eine Exception, oder?
    Nö. Die Aufgabe der Methode ist doch eindeutig zu prüfen (und zu beantworten), ob die Heirat möglich ist. Also würde ich ein BOOL nutzen. Im Gegensatz könnte eine Methode heirate() eine Exception werfen, wenn sie trotz negativer Prüfung trotzdem aufgerufen wird. Das ist eine echte Ausnahme.
    Für das Beispiel böte sich allerdings auf jeden Fall an:
    PHP-Code:
    if ($person1->mAllowed() && $person2->mAllowed()) {
      try {
        
    $person1->marry($person2);
      }
      catch (
    PersonException) {
        ...
      }

    [COLOR="#F5F5FF"]--[/COLOR]
    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
    [COLOR="#F5F5FF"]
    --[/COLOR]

    Kommentar


    • #17
      Bei dem Fall oben hat es sich bewährt, alle Prüfungen durchzuführen und die Fehler in einer Klassenvariable quasi zu sammeln. Die Funktion selber gibt einen boolschen Wert zurück. Die aufgetretenen Fehler holt man sich dann ggf. über eine Extra-Funktion.

      Hier sind Exceptions ungeeignet, da Du dann immer nur einen Fehler bekommst, auch wenn vielleicht mehrere vorhanden sind.

      Wobei das von Nikosch auch nicht schlecht ist. Hier könnte man, wenn das geht, der Exception als Message ein Array mit Fehlern übergeben. Allerdings würde das das Problem nur in die Funktion marry verlagern.

      Kommentar


      • #18
        Fehlerspeicher haben imho immer das Problem, dass sie nicht zwingend mit dem aktuellen Sttaus des Objekts synchron sind. Die muss man resetten etc.
        [COLOR="#F5F5FF"]--[/COLOR]
        [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
        [COLOR="#F5F5FF"]
        --[/COLOR]

        Kommentar


        • #19
          Das ist klar. Aber wie wolltest Du hier dem Benutzer alle Fehler, die aufgetreten sind, auf einmal präsentieren? Bei jedem Versuch des Benutzers, bei dem etwas falsch ist, lediglich eine Fehlermeldung ausgeben zu können, kann etwas nervig werden, wenn es mehrere sind..

          Kommentar


          • #20
            Auch das kommt auf den Anwendungsfall an. Nicht immer ist die Warum-Information wichtig. Und auch nicht immer steckt ein Dialog mit einem Benutzer hinter solchen Prüfungen.
            [COLOR="#F5F5FF"]--[/COLOR]
            [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
            [COLOR="#F5F5FF"]
            --[/COLOR]

            Kommentar


            • #21
              Ok, wie ich sehe ist mein Problem zu Allgemein um Regeln abzuleiten. Zumindest weiß ich nun, wofür man Exceptions nicht verwenden sollte. Vielen Dank für die schnellen und kompetenten Antworten.

              Kommentar


              • #22
                Das ist richtig, aber aus meiner Erfahrung ist es so, dass die Fehler in 99% der Fälle relevant sind, da die meisten Aktionen durch eine Aktion des Benutzers ausgelöst werden (Irgendwas erstellen, bearbeiten, löschen, verheiraten, was auch immer) und schon aus Performance-Gründen immer alle Fehler mit einem Mal ausgegeben werden.

                Kommentar


                • #23
                  Dann finde ich allerdings bereits Exceptions schon fehl am Platz. Informationen, die an den Nutzer rausgehen sind IMHO per Definition keine Ausnahmen, sondern erwartetes (vorhersehbares) Programmverhalten. Eine Person kann verheiratet sein, das ist kein Ausnahmefall. Der Versuch, diese Person trotzdem zu verheiraten ist einer - weil eine vorhergehende Prüfung nicht erfolgt ist oder nicht beachtet wurde..

                  Ich lege Exceptions auch prinzipiell technisch an, d.h. technische Fehlermeldungen, keine die für den Endnutzer bestimmt sind.
                  [COLOR="#F5F5FF"]--[/COLOR]
                  [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                  „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                  [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                  [COLOR="#F5F5FF"]
                  --[/COLOR]

                  Kommentar


                  • #24
                    So meinte ich das ja auch. Exceptions wären hier nur angebracht, wenn mann man marry() ohne explizite Prüfung durchführen würde.

                    Kommentar


                    • #25
                      Zitat von xm22 Beitrag anzeigen
                      Exceptions wären hier nur angebracht, wenn mann man marry() ohne explizite Prüfung durchführen würde.
                      Haha, trifft auch auf die echte Welt da draußen zu. Amen

                      Kommentar


                      • #26
                        Hallo,

                        bin durch die Forensuche auf diesen Thread gestossen. Ich hoff es ist OK wenn ich ihn nochmal aufwärme, auch wenn meine Frage eher ins Anfängerforum gehört.

                        Versuche gerade herauszufinden, wann eine Exception verwendet werden sollte bzw. wann man z.B. false zurückliefert und ggf. eine normale Fehlermeldung ausgibt.

                        Hab schon ne Weile gesucht, aber finde meistens nur Aussagen wie "ICH mache das so", "ICH finde man sollte es so machen" usw.
                        Gibt es dafür keine allgemein gültige Regel oder hab ich sie einfach noch nicht gefunden oder verstanden?

                        nikosch Aussage hilft mir da schon ein wenig weiter bzw. deckt sich mit vielen Aussagen die ich bisher gelesen habe:
                        Ich lege Exceptions auch prinzipiell technisch an, d.h. technische Fehlermeldungen, keine die für den Endnutzer bestimmt sind.
                        aber so ganz versteh ich das leider (noch) nicht.
                        Wie ist technisch in diesem Fall gemeint? Und wenn diese Fehler nicht für den Endnutzer bestimmt sind, wie reagiert man wenn sie in einem Live-System auftreten und die Anwendung deshalb nicht fortgesetzt werden kann?

                        Das Beispiel mit dem verheiraten ist mir leider auch zu hoch *schäm*
                        Hilfe, mein Ball ist umgekippt!

                        Kommentar


                        • #27
                          Gibt es dafür keine allgemein gültige Regel
                          Dann gäbe es diesen Thread nicht Es gibt höchstens ein paar Orientierungspunkte, die wiederum aber von jedem anders priorisiert werden..

                          Technisch meint, dass z. B. ein Fehler in der DB auftritt - Das soll nun natürlich nicht beim Benutzer ankommen, für die Applikation bzw. der Entwickler ist es hingegen schon wichtig, das mitzubekommen.

                          An so einer Stelle hat es sich m. E. nach durch gesetzt, dem Benutzer eine allgemeingültige Fehlermeldung zu präsentieren (Z. B. "Ein technischer Fehler ist aufgetreten. Bitte versuchen Sie es in ein paar Minuten noch einmal"), oder den Grund andernweitig zu verschleiern. Das sollte man allerdings natürlich so gering wie möglich halten

                          Kommentar


                          • #28
                            Muss eigentlich eine Exception immer ein Fehlerfall sein?

                            Ich hatte mal einen Sudokusolver geschrieben. Der hat diverse Lösungsalgorithmen durchgeackert, auf verschiedenen Ebenen: Feld - Zeile, Spalte, Block - Zelle. Im Endefekt waren es mehrere geschachtelte Schleifen.
                            Je nachdem, wo eine Lösung gefunden wurde, habe ich ein Lösungsobjekt zurückgegeben, also über mehrere Iterationsstufen von unten nach oben.

                            Ein erfahrener JAVA-Entwickler meinte, ich solle besser eine Solving-Exception auslösen - ich habe mich aber letztendlich doch dagegen entschieden.

                            Was meint ihr, ist das ein Missbrauch von Exceptions, oder ein legitimes Vorgehen?

                            Kommentar


                            • #29
                              Naja, @beide Fragesteller, diese Frage kann man nicht allgemeingültig beantworten und es gibt zum Glück nicht auch noch dafür ein Gesetz oder eine verbindliche Vorgabe.
                              Die Verwendung und die Legitimation ist schon recht subjektiv, was den Solver anbelangt erreicht das Dimensionen wie die klassische Diskussion um vorzeitige Schleifenabbrüche oder gar die goto-Anweisung, die in PHP z.B. (aktuell noch) verpönt ist, in anderen Sprachen vielleicht Gang und Gäbe.

                              Exceptions sind sehr mächtig, weil sie durch die gesamte Applikationsstruktur fließen, bis zum obersten Script des Aufrufsstacks. Das macht sie gleichermaßen gefährlich, weil man schnell die Übersicht verlieren kann
                              - woher ein Fehler plötzlich kommt
                              - wo zum Teufel mein frisch geworfener Fehler ausgewertet wird.
                              Gerade, weil fehlererzeugender Kontext und aufrufender Kontext nicht zwingend vom selben Programmierer stammen müssen können diese Fragen schnell relevant werden.

                              Kurz zur Auswertung: Sicher wird man zustimmen, dass eine Auswertung an oberster struktureller Ebene für den Anwennder kaum mehr Sinn macht - alle Ausgabe und grafischen Ebenen sind hier durchlaufen und der Nutzer bekommt bestenfalls eine Textmeldung. Eine grafische Auswertung (z.B. eine Fehlerseite im Seitenlayout) kann auf der anderen Seite vielleicht gar nicht funktionieren, weil das Layout aus Modulen oder gar Datenbankzugriffen gebildet wird. Tritt gerade dort der Fehler aus, kann das dann nicht funktionieren.

                              Vielleicht mal ein paar Punkte zum Nachdenken.
                              [COLOR="#F5F5FF"]--[/COLOR]
                              [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                              [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                              [COLOR="#F5F5FF"]
                              --[/COLOR]

                              Kommentar


                              • #30
                                Danke für die Antworten!

                                Kurz zur Auswertung: Sicher wird man zustimmen, dass eine Auswertung an oberster struktureller Ebene für den Anwennder kaum mehr Sinn macht - alle Ausgabe und grafischen Ebenen sind hier durchlaufen und der Nutzer bekommt bestenfalls eine Textmeldung. Eine grafische Auswertung (z.B. eine Fehlerseite im Seitenlayout) kann auf der anderen Seite vielleicht gar nicht funktionieren, weil das Layout aus Modulen oder gar Datenbankzugriffen gebildet wird. Tritt gerade dort der Fehler aus, kann das dann nicht funktionieren.
                                Du machst mich fertig, nikosch
                                Also ich versteh schon wie du das meinst. Jetzt bin ich aber soweit zu sagen:
                                - Exception nur dann, wenn die Applikation nicht weitergeführt werden kann (z.B. Datenbankzugriff fehlgeschlagen) -> einfache Fehlerseite mit einer Meldung wie von xm22 beschrieben. Ein eleganter Ersatz für die()?! hehe
                                ... dem Benutzer eine allgemeingültige Fehlermeldung zu präsentieren (Z. B. "Ein technischer Fehler ist aufgetreten. Bitte versuchen Sie es in ein paar Minuten noch einmal"), oder den Grund andernweitig zu verschleiern. ...
                                - für alle anderen Fehler ein normaler Textstring der an entspr. Stelle im Template eingebaut wird

                                Keine Ahnung ob das Sinn macht. Ein Java-Entwickler würde wahrscheinlich die Hände über dem Kopf zusammenschlagen
                                Ich kann natürlich nur auf Erfahrungen aus meinen Mini-Applikationen bzw. Spielerein zurückgreifen, in diesen Fällen ist aber dieses Vorgehen irgendwie logisch für mich.
                                Hilfe, mein Ball ist umgekippt!

                                Kommentar

                                Lädt...
                                X