An sich ist das hier vollkommen logisch und man wundert sich warum man diesen Fehler überhaupt gemacht hat.. weil man den vorher nicht gemacht hat. Deswegen sollte man im Kopf behalten, dass wenn man optionale Parameter im Methodenaufruf im REST-Controller in Spring hat, diese null als Wert haben können müssen.
Einfach gesagt Integer verwenden und nicht int, weil das natürlich Probleme geben würde, wenn Spring null in einen int füllen möchte.
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.
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?