Neues YouTube-Video: Visualisierung im Devices-Adapter

[Mic]

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.

[foxriver76]

@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. ;-)

[sigi234]

@Mic
@foxriver76

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

[darkiop]

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

[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]

@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