Absturz nach "unexpected end of string while parsing JSON string"

Det20 · 30 Oktober 2017, 12:12:18

Hallo,

mal ne blöde Frage: Mir ist mal wieder die FHEM Instanz abgestürzt, die letzte Meldung im Log war "unexpected end of string while parsing JSON string, at character offset 1430 (before "(end of string)") at ./FHEM/48_HomeConnect.pm line 760". Könnte man im FHEM nicht ein Flag, vergleichbar wie "On Error Resume Next"? Das FHEM halt nicht abstürzt wenn so ein Fehler auftritt, sondern nur das entsprechende Modul (logsgelöst von HomeConnect)?

CoolTux · 30 Oktober 2017, 12:15:09

Es wird empfohlen JSON Funktionen immer in einem eval auf zu rufen. Dann passiert sowas nicht.

Thorsten Pferdekaemper · 30 Oktober 2017, 12:40:44

Zitat von: CoolTux am 30 Oktober 2017, 12:15:09
Es wird empfohlen JSON Funktionen immer in einem eval auf zu rufen. Dann passiert sowas nicht.

Da hast Du sicher Recht. Allerdings: Wenn man Deine Aussage etwas verallgemeinert, dann steht da "Darum müssen sich die Modulentwickler kümmern.". Das ist sicher auch richtig, aber es ware ja schon schöner, wenn nicht ein (unwichtiges?) Modul den ganzen FHEM-Prozess sterben lassen würde. Auf der anderen Seite ist es natürlich auch schwierig im Allgemeinen zu entscheiden, ob ein Fehler so schlimm ist, dass man besser alles stoppt oder ob es vertretbar ist, wenn der Rest weiterläuft.
Allerdings habe ich dazu auch keine so richtig gute Idee...
Gruß,
Thorsten

CoolTux · 30 Oktober 2017, 12:58:52

Zitat von: Thorsten Pferdekaemper am 30 Oktober 2017, 12:40:44
Da hast Du sicher Recht. Allerdings: Wenn man Deine Aussage etwas verallgemeinert, dann steht da "Darum müssen sich die Modulentwickler kümmern.". Das ist sicher auch richtig, aber es ware ja schon schöner, wenn nicht ein (unwichtiges?) Modul den ganzen FHEM-Prozess sterben lassen würde. Auf der anderen Seite ist es natürlich auch schwierig im Allgemeinen zu entscheiden, ob ein Fehler so schlimm ist, dass man besser alles stoppt oder ob es vertretbar ist, wenn der Rest weiterläuft.
Allerdings habe ich dazu auch keine so richtig gute Idee...
Gruß,
Thorsten

Da möchte ich gerne den Rudi zitieren

Zitat
Das ist eine Philosophie-Frage, und kein Fehler. die() im perl kann man mit throw() in Java vergeleichen, d.h. es wird ein Exception generiert. In Java ist ein Exception mit catch, in perl mit eval abzufangen. Ob das guter oder schlechter Programmierstil ist, darueber kann man stundenlang streiten. Ich bin auf der Seite der "Rueckgabewert statt Exception" Verfechter, weil ich in Java-Umfeld haeufig sehe, dass die Exceptions nur sehr weit entfernt vom Problem abgefangen werden, wo man nicht mehr in der Lage ist, eine richtige Fehlermeldung zu generieren. Im Log sieht man dann neben der Meldung "No such file or directory" den kompletten Callstack, aber man weiss nicht, welche Datei nun fehlt. Man _kann_ auch mit Exceptions sauber programmieren, passiert nur meiner Erfahrung nach seltener. Wie man das in unserem Beispiel auch sieht.

https://forum.fhem.de/index.php/topic,76842.msg689593.html#msg689593

Grüße

Det20 · 30 Oktober 2017, 13:31:28

Ich gebe Dir Recht, es liegt am Modul-Entwickler, ein Try...Catch einzubauen. Nur sollte so etwas nicht FHEM in den Tot reißen, ich habe als Anwender ja kaum Einfluß auf die Arbeit vom Modul-Entwickler.

Es wäre unter Windows, Linux und co fatal, wenn jede nicht abgefangene Exception das gesamte Windows mit in den Abgrund zieht. Wieso also nicht die Logik auch in FHEM einbauen, wenn es möglich ist (ich weiß nicht, ob es möglich ist bzw wie aufwendig). In der Praxis arbeite ich inzwischen mit Scripten die alle 30 Minuten schauen, ob FHEM noch lebt. Kann es ja eigentlich irgendwie auch nicht sein.

CoolTux · 30 Oktober 2017, 13:45:50

Ist auch nicht nötig. Mein FHEM läuft 24x7 und das auch schon Mal 30 Tage ohne Update. Hatte bisher noch keine solche Problem. Mach einfach den Entwickler auf das Problem aufmerksam. Jeder vernünftig Entwickler möchte das sein Software sauber läuft. Zu mindest so das FHEM nicht in den Tod geht.

viegener · 30 Oktober 2017, 13:46:21

Zitat von: Det20 am 30 Oktober 2017, 13:31:28
Es wäre unter Windows, Linux und co fatal, wenn jede nicht abgefangene Exception das gesamte Windows mit in den Abgrund zieht. Wieso also nicht die Logik auch in FHEM einbauen, wenn es möglich ist (ich weiß nicht, ob es möglich ist bzw wie aufwendig). In der Praxis arbeite ich inzwischen mit Scripten die alle 30 Minuten schauen, ob FHEM noch lebt. Kann es ja eigentlich irgendwie auch nicht sein.

Generell ist es sicher unschön wenn FHEM abstürzt, aber auch kommerzielle Software wird in Rechnezntren mit solchen Skripten überwacht und bei Bedarf neugestartet. Ich nutze übrigens so etwas nicht, mein FHEM läuft auch mal mehrere Wochen durch, obwohl meine eigenen Module verwendet werden

Als Modulentwickler und Anwender kann ich sagen, dass die Meldung solcher Fehler in fast allen Fällen kurzfristig von den Autoren gelöst wird und damit alle profitieren, wenn es einfach im log verscwände, wäre es schade, denn die Fehlermeldung würde vermutlich unterbleiben. Die module sind ja Teil von FHEM und damit passt der Vergleich zu Windows eigentlch nicht / das Linux läuft ja auch weiter...