Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Entwicklung
    4. Adapter: Error Handling Frage

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    Adapter: Error Handling Frage

    This topic has been deleted. Only users with topic management privileges can see it.
    • Mic
      Mic Developer last edited by

      Hi,

      siehe js-Controller issue 947: https://github.com/ioBroker/ioBroker.js-controller/issues/947

      getForeignObjectAsync() wirft einen Fehler, wenn das übergebende String nicht passt, aber nur wenn try/catch verwendet wird.
      Ich persönlich tendiere dazu, Variablen, die ich an eine Funktion übergebe, vorher schon zu validieren und dann auch innerhalb der Funktion abzubrechen und z.B. return=false zu machen falls nicht erfolgreich.
      try/catch ist eher Neuland für mich. Soll man jetzt unter node.js/Javascript jetzt echt alles auf "try/catch" basieren, und nur dann Fehler werfen, wenn catch erreicht wird?
      Macht ja vieles einfacher, aber widerspricht meiner bisherigen Logik.
      Eure Meinungen dazu?

      Ich bin kein JS Pro, daher frage ich 🙂

      Danke.

      Mic-M created this issue in ioBroker/ioBroker.js-controller

      closed No input validation for getForeignObjectAsync() and possibly similar functions #947

      foxriver76 sigi234 2 Replies Last reply Reply Quote 0
      • foxriver76
        foxriver76 Developer @Mic last edited by

        @Mic Der Fehler (UnhandeledPromiseRejection in diesem Fall) fliegt unabhängig vom try/catch. Ein Controller > 3 wird deinen Adapter dann auch sofort killen. Wenn du async/await nutzt, ist es in den meisten Fällen sinnvoll, ein try/catch um deinen await tueDiesDas() zu machen, da du nur so eine Promise Rejection fange kannst bei der Nutzung von async/await. Die Alternative sind klassische Promises a la

        getForeignObjectAsync('tolleradapter.0.tollerstate').then(state => adapter.log.info(state.val)).catch(e => adapter.log.error('error caught: ' + e));
        

        oder Callbacks a la

        getForeignObject('tolleradapter.0.tollerstate', (err, state) => {
           if (err) {
              adapter.log.error('error: ' + err);
           } else {
              adapter.log.warn(state.val);
           }
           setState('asasf', err => {
              // wir rücken immer weiter ein wenn etwas synchron passieren muss -> Callback Hell
           });
        });
        

        Die Logik ist bei den Promises, immer wenn ein Error Callback zurückgegeben wurde, wird das Promise nun rejected und muss in einer Form gefangen werden.

        Ich persönlich finde async/await am schicksten + leserlichsten. async/await sind jedoch nur Promises in außergewöhnlicher Tarnung. 😉

        Mic 1 Reply Last reply Reply Quote 1
        • sigi234
          sigi234 Forum Testing Most Active @Mic last edited by

          @Mic
          @foxriver76

          Ich hau mich nieder, das ist der 1.Beitrag wo ich keinen einzigen Satz verstehe. 😀 😖

          D 1 Reply Last reply Reply Quote 0
          • D
            darkiop Most Active @sigi234 last edited by

            @sigi234 ich hab ihn auch 2x gelesen, aber dann aufgegeben 😂

            1 Reply Last reply Reply Quote 0
            • Mic
              Mic Developer @foxriver76 last edited by Mic

              @foxriver76
              Danke für deine ausführliche Erklärung 🙂
              In meiner bisherigen Programmierwelt anderer Script-Sprachen war ein Fehler immer schlecht, und man versuchte vorher abzufangen, was geht. Aber da muss ich in JS etwas umdenken...
              try/error habe ich grundsätzlich in jeder (async)-Funktion drin, aber nur global. Ich werde nun bei Bedarf auch try/error auf spezifische Calls ausführen, um im error besser darauf reagieren zu können.

              Für mich ist async/await auch am schönsten, macht es echt einfach und super leserlich. Ich muss als async/await-Einsteiger aber noch aufpassen, nicht zu übertreiben, und genau zu entscheiden, wann ich "await" auch wirklich brauche, damit nix bremst.

              @sigi234 @darkiop
              Ach, so ging es mir auch, als ich das erste mal von Promises gelesen hatte 😀
              bluefox und Team sei dank, dass wir die "Probleme" im JavaScript-Adapter in JS und Blockly quasi nicht wahrnehmen, da vieles im Hintergrund des JS-Adapters bereits gerade gebogen wird.
              Bei der Adapter-Programmierung geht es aber rauer zu, da ist man nicht abgefedert durch den JS-Adapter. Außerdem programmiert man für viele und hat Verantwortung, da ist ein ganz anderes Error Handling usw. gefordert.
              Und man muss darauf aufpassen, dass bei einem Funktionsaufruf was gutes zurückkommt, auch falls das erst zeitverzögert kommt (z.B. Auslesen einer Website, Datenpunkt abfragen, etc.). Diese Zeitverzögerung muss man handhaben im Code, weil der sonst weiter durchrattern würde und bevor die Infos vorliegen, wäre das Script schon durchlaufen. Da kommen jetzt Promises und async/await ins Spiel.
              Gute Anlaufstelle: javascript.info: Promises, async/await

              foxriver76 1 Reply Last reply Reply Quote 0
              • foxriver76
                foxriver76 Developer @Mic last edited by foxriver76

                @Mic sagte in Adapter: Error Handling Frage:

                Gute Anlaufstelle: javascript.info: Promises, async/await

                Auch hilfreich zur Umstellung, könnte https://gist.github.com/AlCalzone/d14b854b69ce5e8a03718336cc650a95 sein.

                Für mich ist async/await auch am schönsten, macht es echt einfach und super leserlich. Ich muss als async/await-Einsteiger aber noch aufpassen, nicht zu übertreiben, und genau zu entscheiden, wann ich "await" auch wirklich brauche, damit nix bremst.

                Du kannst durchaus auch mehrere Promises parallel laufen lassen und erst nachdem alle ausgeführt worden sind, weiter machen, via Promise.all

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post

                Support us

                ioBroker
                Community Adapters
                Donate

                815
                Online

                31.8k
                Users

                80.0k
                Topics

                1.3m
                Posts

                error handling javascript node js
                4
                6
                619
                Loading More Posts
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes
                Reply
                • Reply as topic
                Log in to reply
                Community
                Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                The ioBroker Community 2014-2023
                logo