Wenn man in Shopware den Cache geleert hat und beim Anlegen der Keywords im Frontend danach eine Exception auftritt, die in etwas so "General error: 1436 Thread stack overrun" lautet, muss man die MySQL-DB anpassen.
Dafür muss man in der my.conf den Wert für den thread_stack erhöhen.
Ich hatte einfach keine Lust eine neue Modul-Version in meinen lokalen 10er zu basteln. Also auch wenn man seit JBoss 7 an sich Pause hatte und erst jetzt wieder mit WildFly 10 angefangen hat... es sind immer noch genau die selbe Art von Problemen die einen Ärgern.
PHP kann ja Zahlen, die als String vorliegen, direkt als Zahl casten. Was sich erst einmal ganz praktisch anhört ist leider sehr seltsam umgesetzt, da nie validiert wurde, ob der String im Ganzen eine gültige Zahlennotation enthält.
$a = "05" + "10dings";
Der Ausdruck liefert 15 zurück. Jeder aus Java Integer.parseInt() kennt, wird es bei so einem Umgang nur kalte Scheuer über den Rücken jagen.
Einige halten dieses Verhalten zwar für vollkommen korrekt und besonders praktisch, weil einem so der Benutzer durch unsinnige Eingaben die Berechnung nicht kaputt machen kann... aber wenn man mal ehrlich ist, ist "5 stück" + "0.5 eier" + "draussen dunkel" = int(5.5) nicht wirklich ein brauchbares Ergebnis.
Ja da kommt wirklich 5.5 raus.
Aber zum Glück gibt es jetzt mit 7.1 wenigstens eine kleiner Verbesserung. Es wird eine Warnung geworfen.
Number operators taking numeric strings now emit E_NOTICEs or E_WARNINGs when given malformed numeric strings.
Damit ist man schon mal soweit, dass man seinen Code sicher machen kann, wenn man möchte. Man muss es leider nicht, aber dass man es kann ist schon mal ein Fortschritt.
Elastica ist sehr radikal was deprecated Methoden angeht. Es werden nicht einfach nur Warnings angezeigt sondern gleich Exceptions geworfen. Deprecated Warning ignoriert man gerne. Besonders wenn man aus dem Java-Bereich kommt, weil dort ist man gewohnt (Beispiel die Date-Klasse), dass Methoden zwar deprecated sind, aber ewig weiter existieren und dass meistens auch weiterhin fehlerfrei- Die wurden meistens nur deprecated, weil die Funktionalität in eine andere Klasse verschoben wurde oder es eine neue Funktionalität gibt, die mehr kann und die alte voll umfassend ersetzen kann.
Das werfen von Exceptions, die man mit Try-Catch auffangen könnte motiviert aber ungemein, gleich alles auf das neue Vorgehen umzubauen. Warnings sind ok.. Exception dürfen aber nicht sein. Das Warning ignoriert oder gleich ganz abgeschaltet werden führt auch immer wieder zu "lustigen" Vorkommnissen. "Wieso hast du einfach die Methode gelöscht.. die hab ich an mehreren Stellen verwendet!" - "1. war sie fast 10 Monate als Deprecated markiert.." - "... Warning hab ich abgeschaltet.. waren zu viele.." - ".. und 2. soll bitte die Service-Schnittstelle des Modules genutzt werden,weil dort wurde schon vor 11 Monaten auf die neue und schnellere Methode umgestellt"
Man sollte seinen Code immer Warning-frei halten und nicht einfach Warning ignorieren, weil man ein paar einfach nicht entfernen kann, weil z.B. der Code-Parser der IDE glaubt er könnte das SQL-Statement, dass aus mehreren Strings zusammen gebaut wird brauchbar auf Fehler untersuchen.
Das man in einer PHP-Seite mal in eine Exception läuft ist ja nicht schlimm, nervig ist nur, wenn man merkt, dass diese Exception wiederum aus einen catch-Block stammt und man erst einmal Debuggen muss, um an die original Exception zukommen und den wirklichen Fehler zu sehen.
try{
$a = 1* array(2,3);
}
catch(Exception $e){
throw new Exception("something went wrong");
}
Man sollte immer, wenn es mögich ist, die original Exception mit an die eigene Exception ran hängen.
try{
$a = 1* array(2,3);
}
catch(Exception $e){
throw new Exception("something went wrong", 0, $e);
}
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?