Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Propagieren von Exceptions

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Propagieren von Exceptions

    Hi,
    ich schreibe grade eine Zend_Server_... Klasse die einen Webservice abfragt. Im Grunde nutz ich dafuer Zend_Http_Client und Zend_Json.

    Angenommen es werden jetzt durch diese zwei Klassen Exceptions geworfen, weil z.b. keine HTTP Verbindung hergestellt werden kann oder weil das gelieferte JSON "kaputt" ist. Beides sind Fehler die ich nicht wirklich durch meine Klasse korrigieren oder abfangen kann.

    Sollte ich diese Exceptions jetzt einfach weiterreichen und der Nutzer muss dann mit den Exceptions die meine Klasse wirft UND den Exceptions die von anderen Klassen geworfen werden umgehen? Oder sollte ich diese Exceptions abfangen und z.B. durch die Exception austauschen die auch meine Klasse schon wirft?

    Ansich wuerde ich ja die Exceptions einfach weiterreichen lassen, aber dann muesste der Nutzer meines Services ja ueber alle Exceptions die irgendwie auftauchen koennen bescheid wissen.

    Wie macht ihr das oder wie wird sowas in der Regel gemacht?


  • #2
    Ich würde eine eigene Exception werfen. Somit kannst du auch später Komponenten noch austauschen, die möglicherweise wieder andere Exceptions werfen, ohne dass der User, der dein Paket nutzt, etwas anpassen muss.

    So muss sich der User immer nur um deine Exceptions kümmern.

    VG

    Kommentar


    • #3
      Dafür gibts das Konzept der "inner exception". Im grunde machst du eine "eigene" Exception um die herum, die von Zend erzeugt wird.

      Von außen wirft deine Klasse nur den "MyException"-Typ. Darin gekapselt sind tatsächlich aber die Exceptions, die von den anderen Klassen kommen, die du verwendest.

      Bin mir nicht sicher, ob es das in PHP gibt (nativ definitiv nicht), d.h. du müsstest irgendeine Form finden, in der du die Daten der inneren Exception weiterreichen kannst (Feld in deinem Exception-Objekt z.B.).

      Denn eines ist sicher: Verschlucken solltest du auf keinen Fall irgendwelche Daten, mit denen deine Klasse nicht umgehen kannst. Sonst ist der ganze Sinn von Exceptions dahin.
      Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

      Kommentar


      • #4
        Ich würde eine eigene Exception werfen. Somit kannst du auch später Komponenten noch austauschen, die möglicherweise wieder andere Exceptions werfen, ohne dass der User, der dein Paket nutzt, etwas anpassen muss.

        So muss sich der User immer nur um deine Exceptions kümmern.
        Dem ist nichts hinzuzufügen.
        --

        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


        --

        Kommentar


        • #5
          Zitat von nikosch Beitrag anzeigen
          Dem ist nichts hinzuzufügen.
          Vielleicht doch: Eigene Exception mit der eigentlichen Exception der Komponente innerhalb deines Klassen-Workspaces als Previous-Exception

          PHP-Code:
          try {
             
          Dingens();
          }
          catch ( 
          DingensException $e ) {
             throw new 
          PackageException('Irgendwas is hier falsch'500$e);

          [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

          Kommentar


          • #6
            Stümmt, exception chaining.
            --

            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


            --

            Kommentar


            • #7
              Wie sie alle meinen Beitrag ignorieren

              Spaß beiseite, mach es so wie von allen hier gesagt. Im Zweifelsfall einfach \Exception catchen und deine davor schalten.
              Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

              Kommentar


              • #8
                Okay ich hatte das bis jetzt auch nach der Art gelöst, ich dachte nur immer dabei an das unnötige Wrappen von Dingen mit den "selben" Dingen. Z.B. wie einen Wrapper für PDO oder ähnliches

                Das Exception-Chainig kannte ich noch nicht, das werd ich dann noch mit einbauen.

                Danke für die Anregungen.

                Kommentar


                • #9
                  Was würde Florian nur ohne diesen qualitativ hochwertigen Beitrag machen?
                  Crashkurs zum Thema Rechtschreibung: normalerweise (normaler weise oder normaler weiße), Standard (Standart), eben (ebend)

                  Kommentar


                  • #10
                    Exception-Chaining ist ein integraler Bestandteil der Programmierung und sollte dem Programmierer in Fleisch und Blut übergehen. Als kleines Beispiel zum Verständnis für dich Flor1an: Angenommen wir haben ein Programm mit Methoden, die andere Methoden aufrufen, welche möglicherweise Exceptions werfen. Dabei besteht natürlich der Fall, dass lange Exceptionsignaturen durch das Einsammeln der Exceptionsignaturen von allen Methoden, die gerade aufgerufen werden, auftreten können (exception poisoning). Das Blöde daran ist, dass eine Änderung der Exceptionsignatur von einer untergeordneten Methode die Anpassung aller aufzurufenden Methoden vorraussetzt, was dich mit normalen Exceptions vor ein riesiges Problem stellt und dabei hilft eben Exception-Chaining Abhilfe.

                    Kommentar

                    Lädt...
                    X