[Gelöst]Fehler abfangen, aber wie richtig?

fastfoot

@xenon sagte in Fehler abfangen, aber wie richtig?:

@fastfoot reden wir jetzt von einem eigenen Adapter oder vom js Adapter?

wir reden von einem normalen Skript, welches bei falschem Pfad den Adapter abstürzen lässt. Ein try/catch hilft nicht dagegen und ich wollte wissen warum

Xenon

@fastfoot müsste ich morgen mal ausprobieren

fastfoot

@xenon sagte in Fehler abfangen, aber wie richtig?:

@fastfoot müsste ich morgen mal ausprobieren

probiert habe ich ja schon, ich hatte gehofft ein JS guru hier wüsste warum das nicht abgefangen wird. Und eine Lösung habe ich ja auch, würde aber gerne aus einer Antwort lernen können :-) DAnke fürs Anschauen

MCU

@fastfoot Dann mach ein Issue im javascript-Adapter auf:
https://github.com/ioBroker/ioBroker.javascript/issues

fastfoot

@mcu sagte in Fehler abfangen, aber wie richtig?:

@fastfoot Dann mach ein Issue im javascript-Adapter auf:
https://github.com/ioBroker/ioBroker.javascript/issues

ähem, nein! Ich denke es ist/war mein Fehler, zu denken dass try/catch einen solchen Fehler abfängt. Ich hätte nur gerne eine Erklärung dazu gehabt warum das nicht funktioniert(funktionieren kann). der Fehler wird ja eigentlich im fs Modul nicht abgefangen und ich glaube nicht dass der JS-Adapter da noch viel tun kann.

OliverIO

@fastfoot

das Problem ist nicht der Befehl createWriteStream sondern der axios Befehl danach.
Verschiebe ich den Befehl auch in den try-block dann erscheint im log auch der Fehler

wenn man dann noch an catch den error parameter übergibt und den über das log ausgibt, dann erscheint folgendes:

javascript.0 (22209) script.js.Test.Skript_1: {'message':'write EPROTO 140638061451136:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../deps/openssl/openssl/ssl/statem/statem_clnt.c:2158:\n','name':'Error','stack':'Error: write EPROTO 140638061451136:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../deps/openssl/openssl/ssl/statem/statem_clnt.c:2158:\n\n at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:94:16)','config':{'url':'https://covid19-dashboard.ages.at/data/CovidFaelle_Timeline_GKZ.csv','method':'get','headers':{'Accept':'application/json, text/plain, */*','User-Agent':'axios/0.21.1'},'transformRequest':[null],'transformResponse':[null],'timeout':0,'responseType':'stream','xsrfCookieName':'XSRF-TOKEN','xsrfHeaderName':'X-XSRF-TOKEN','maxContentLength':-1,'maxBodyLength':-1},'code':'EPROTO'}

der server hat wohl ein problem mit der ssl konfiguration. da muss man bei axios wohl noch den ein oder anderen parameter mit angeben, damit die prüfung ausgeschaltet wird.

weiß nicht genau was du vorhast.
aber wahrscheinlich könntest du dir es einfacher machen direkt über die json daten zu gehen und nicht erst das csv runter zu laden, das einzulesen und daraus die richtigen daten identifizieren.

https://covid19-dashboard.ages.at/data/JsonData.json

die daten sehen ganz gut strukturiert aus

Xenon

@oliverio hatte es auch grade getestet, komme zum gleichen Ergebnis
@fastfoot Das was da das Ziel ist, kann das nicht der corona Adapter vom dutch bereits?

Latzi

@xenon sagte in Fehler abfangen, aber wie richtig?:

kann das nicht der corona Adapter vom dutch bereits?

nein, leider nicht auf Bezirks-/Bundeslandebene für Österreich :-(

fastfoot

@oliverio sagte in Fehler abfangen, aber wie richtig?:

das Problem ist nicht der Befehl createWriteStream sondern der axios Befehl danach.

Danke für den ausführlichen Kommentar. Aber hast du mal einen falschen Dateipfad angegeben? Da zeigt sich doch erst der Absturz von dem ich rede(Adapter-Neustart). Das in deinem Log gezeigte SSL-Problem hatte ich auch beschrieben und wie es derzeit behoben werden kann, aber es lässt den Adapter ja nicht neu starten

fastfoot

@xenon sagte in Fehler abfangen, aber wie richtig?:

@oliverio hatte es auch grade getestet, komme zum gleichen Ergebnis

siehe meinen anderen Post. Ihr habt beide nicht versucht meinen 'Fehler' nachzustellen, obwohl ich es ausführlichst beschrieben habe. Kommentiere einfach alles nach createWritestream aus und auch die Prüfung mit existsSynch, übergib einen fehlenden Pfad und schau wie der Adapter abstürzt. Und dann sage mir bitte warum das try/catch diesen Absturz nicht verhindert oder verhindern kann.

@fastfoot Das was da das Ziel ist, kann das nicht der corona Adapter vom dutch bereits?

selbst wenn er es könnte, ich habe diese Dinge gerne selbst in der Hand und mir gefällt auch die Art der Datenaufbereitung in einzelne DP nicht, ich mag lieber Tabellen.

fastfoot

@latzi sagte in Fehler abfangen, aber wie richtig?:

@xenon sagte in Fehler abfangen, aber wie richtig?:

kann das nicht der corona Adapter vom dutch bereits?

nein, leider nicht auf Bezirks-/Bundeslandebene für Österreich :-(

Das Skript kann das ja und es gibt auch eine Grafik dazu, muss es denn immer ein Adapter sein?

OliverIO

@fastfoot sagte in Fehler abfangen, aber wie richtig?:

@oliverio sagte in Fehler abfangen, aber wie richtig?:

das Problem ist nicht der Befehl createWriteStream sondern der axios Befehl danach.

Danke für den ausführlichen Kommentar. Aber hast du mal einen falschen Dateipfad angegeben? Da zeigt sich doch erst der Absturz von dem ich rede(Adapter-Neustart). Das in deinem Log gezeigte SSL-Problem hatte ich auch beschrieben und wie es derzeit behoben werden kann, aber es lässt den Adapter ja nicht neu starten

also ich habe keinen absturz des adapters, wenn ich den request mit axios und der verarbeitung danach auskommentiere.

allerdings wird auch kein fehler geworfen wenn der pfad nicht existiert.

const axios = require('axios').default;                 // In der JS-Instanz unter Module eintragen
//const csvjson = require('csvjson');                     // In der JS-Instanz unter Module eintragen
const fs = require('fs');
const Path = require('path');
const fileName = 'CovidFaelle_Timeline_GKZ.csv';        // Dateiname
const filePath = '/opt/iobroker/iobroker-data/files/Downloadsx';   // Dateipfad
 
// download and save csv file
async function getCSVFile (url) {  
    let writer;
 
    //if(!fs.existsSync(filePath)) return log('Dateipfad existiert nicht!','error');
    log("1");
 
    //try/catch nützt hier nichts wenn filePath nicht existiert!
    log("2");
    try{
        log("3");
        writer = fs.createWriteStream(Path.resolve(filePath, '', fileName));
        log("4");
    }catch {
        log("5");
        log('Fehler');
        log("6");
    }
log("7");
 }
async function main(){
    const url = 'https://covid19-dashboard.ages.at/data/CovidFaelle_Timeline_GKZ.csv';
    await getCSVFile(url);
 }
 main();

log sollte 1 2 3 4 7 ausgeben
Gleiches Ergebnis ob Pfad existiert oder nicht

über zeile 12 fragst du ja ab, ob der pfad existiert und beendest dann. das habe ich für den test mal auskommentiert

das fs.createWriteStream keinen fehler wirft, hängt evtl. mit der fehlerbehandlungs strategie des moduls ab.

fehler werden da normalerweise über ein error-event abgefangen
https://nodejs.org/api/fs.html#fs_event_error

allerdings wird der fehler auch mit folgender code ergänzung geworfen, weil wahrscheinlich es da bereits vorbei ist.

writer.on('error', function(err) {
    log(err);
    writer.end();
});

Einen Fehler darauf findest du hier. Auch wie alternativ der Fehler dann abgefangen werden kann. Im Text wird von Berechtigungsproblemen geschrieben, aber da kannst du es mal probieren.
Aber wie gesagt, mit Zeile 12 ist zumindest das Problem ob Pfad existiert oder nicht ja abgefragt.

https://stackoverflow.com/questions/43293921/cant-catch-exception-from-fs-createwritestream/43303770

fastfoot

@oliverio sagte in Fehler abfangen, aber wie richtig?:

@fastfoot sagte in Fehler abfangen, aber wie richtig?:

@oliverio sagte in Fehler abfangen, aber wie richtig?:

also ich habe keinen absturz des adapters, wenn ich den request mit axios und der verarbeitung danach auskommentiere.

allerdings wird auch kein fehler geworfen wenn der pfad nicht existiert.

Das genau ist bei mir anders. Der Code wie von dir gepostet spiegelt exakt mein 'Problem', er lässt bei mir den Adapter abstürzen. Die Log-Ausgabe stimmt mit deiner überein, wie mein Log zeigt in beiden Fällen. Ich habe die aktuellsten Betas installiert, allerdings ist der Admin auf 4.2.1. Der obere Teil zeigt die Ausgabe mit korrektem Pfad, in Zeile 17 zeigt es den Restart an

javascript.1	2021-04-27 16:20:50.535	info	(30171) script.js._MeineSkripte._DEV.testCSV: registered 0 subscriptions and 0 schedules
javascript.1	2021-04-27 16:20:50.535	info	(30171) script.js._MeineSkripte._DEV.testCSV: 7
javascript.1	2021-04-27 16:20:50.534	info	(30171) script.js._MeineSkripte._DEV.testCSV: 4
javascript.1	2021-04-27 16:20:50.532	info	(30171) script.js._MeineSkripte._DEV.testCSV: 3
javascript.1	2021-04-27 16:20:50.531	info	(30171) script.js._MeineSkripte._DEV.testCSV: 2
javascript.1	2021-04-27 16:20:50.530	info	(30171) script.js._MeineSkripte._DEV.testCSV: 1
javascript.1	2021-04-27 16:20:50.416	info	(30171) Start javascript script.js._MeineSkripte._DEV.testCSV
javascript.0	2021-04-27 16:20:47.930	info	(222) Stop script script.js._MeineSkripte._DEV.testCSV
javascript.1	2021-04-27 16:20:47.919	info	(30171) Stop script script.js._MeineSkripte._DEV.testCSV
javascript.1	2021-04-27 16:19:41.324	info	(30171) received all states
javascript.1	2021-04-27 16:19:41.299	info	(30171) received all objects
javascript.1	2021-04-27 16:19:37.739	info	(30171) requesting all objects
javascript.1	2021-04-27 16:19:37.737	info	(30171) requesting all states
javascript.1	2021-04-27 16:19:37.605	info	(30171) starting. Version 5.1.3 in /opt/iobroker/node_modules/iobroker.javascript, node: v14.16.1, js-controller: 3.2.16
host.iobroker	2021-04-27 16:19:34.142	info	instance system.adapter.javascript.1 started with pid 30171
host.iobroker	2021-04-27 16:19:04.092	info	Restart adapter system.adapter.javascript.1 because enabled
host.iobroker	2021-04-27 16:19:04.091	error	instance system.adapter.javascript.1 terminated with code 1 (JS_CONTROLLER_STOPPED)
host.iobroker	2021-04-27 16:19:04.090	error	Caught by controller[0]: Error: ENOENT: no such file or directory, open '/opt/iobroker/iobroker-data/files/Downloadsx/CovidFaelle_Timeline_GKZ.csv'
javascript.1	2021-04-27 16:19:03.379	info	(30063) script.js._MeineSkripte._DEV.testCSV: registered 0 subscriptions and 0 schedules
javascript.1	2021-04-27 16:19:03.378	info	(30063) script.js._MeineSkripte._DEV.testCSV: 7
javascript.1	2021-04-27 16:19:03.377	info	(30063) script.js._MeineSkripte._DEV.testCSV: 4
javascript.1	2021-04-27 16:19:03.376	info	(30063) script.js._MeineSkripte._DEV.testCSV: 3
javascript.1	2021-04-27 16:19:03.375	info	(30063) script.js._MeineSkripte._DEV.testCSV: 2
javascript.1	2021-04-27 16:19:03.374	info	(30063) script.js._MeineSkripte._DEV.testCSV: 1
javascript.1	2021-04-27 16:19:03.250	info	(30063) Start javascript script.js._MeineSkripte._DEV.testCSV

log sollte 1 2 3 4 7 ausgeben
Gleiches Ergebnis ob Pfad existiert oder nicht

über zeile 12 fragst du ja ab, ob der pfad existiert und beendest dann. das habe ich für den test mal auskommentiert

das ist meine aktuelle Lösung und die funktioniert auch, sie steht da aber nur weil try/catch nicht funktionierte. Jetzt verwundert es mich weshalb bei Dir kein Adapter-Restart durchgeführt wird.

das fs.createWriteStream keinen fehler wirft, hängt evtl. mit der fehlerbehandlungs strategie des moduls ab.

fehler werden da normalerweise über ein error-event abgefangen
https://nodejs.org/api/fs.html#fs_event_error

allerdings wird der fehler auch mit folgender code ergänzung geworfen, weil wahrscheinlich es da bereits vorbei ist.
writer.on('error', function(err) {
    log(err);
    writer.end();
});
Einen Fehler darauf findest du hier. Auch wie alternativ der Fehler dann abgefangen werden kann. Im Text wird von Berechtigungsproblemen geschrieben, aber da kannst du es mal probieren.
Aber wie gesagt, mit Zeile 12 ist zumindest das Problem ob Pfad existiert oder nicht ja abgefragt.

https://stackoverflow.com/questions/43293921/cant-catch-exception-from-fs-createwritestream/43303770

die Antwort habe ich nur zu 90% verstanden, die Leute dort programmieren fast alle in höheren Ligen als ich selbst :-) Aber nur so lernt man etwas, mit der Antwort dort kann ich gut leben und mit writer.on('error',xxx) habe ich nochmal etwas dazu gelernt.

Jetzt bleibt nur noch zu prüfen ob der Adapter auf einem Stable System bei mir anders reagiert, das poste ich dann noch der Vollständigkeit halber.

Dir einen großen Dank für Deine Mühe und Geduld! Der Dank gilt natürlich auch für alle Anderen die sich mit dem Problem beschäftigt haben!

fastfoot

@fastfoot sagte in Fehler abfangen, aber wie richtig?:

Jetzt bleibt nur noch zu prüfen ob der Adapter auf einem Stable System bei mir anders reagiert, das poste ich dann noch der Vollständigkeit halber.

Auch auf einem Stable System beendet sich der Adapter. Mit folgendem Code lässt sich das aber verhindern, try/catch scheint schlicht der falsche Ansatz gewesen zu sein

writer.on('error', function(err) {
    console.log(err);
    writer.end();
});

Community Forum

NEWS

[Gelöst]Fehler abfangen, aber wie richtig?

Support us

525

32.6k

82.2k

1.3m