Menü
Avatar von captmcneil
  • captmcneil

472 Beiträge seit 01.04.2010

Re: Was mich daran nervt...

Geistesgegenwart schrieb am 28.08.2018 17:57:

captmcneil schrieb am 28.08.2018 17:49:

Hinter der "Billion Dollar Mistake"-Aussage steckt ja implizit die Forderung, dass:

- entweder der "."-Operator auf "null" einfach "null" liefern, oder nichts tun sollte, und alle Operatoren auch auf "null" ein definiertes Verhalten haben müssen. So ein bisschen wie NaN in Sprachen wie JavaScript. Das Problem daran ist, dass dieses Verhalten leicht "toxisch" wird, und es Fehler schwerer auffindbar macht.

- oder, dass wir nicht mehr prozedural programmieren sollten (Stichwort Haskell, oder rein funktional, wie Linq & co.). Das ist irgendwie auch keine Lösung.

Nein, das wird so nicht gefordert.

Ich habe meine Argumentation noch etwas erweitert.

Naja, wenn ich sage, dass es eine NullRef-Exception nicht in der Sprache geben sollte, muss der Compiler erzwingen, dass ein "." Aufruf auf ein Nullable-Objekt nicht möglich ist. Oder ein Default-Verhalten implementieren.

Ich ging davon aus, dass dies auch C# nicht können wird, mein Kenntnis-Stand war, dass es Warnings bleiben. Allein schon für Linq-Provider, welche nur Expressions übersetzen können, wären die erzwungenen Null-Checks doch der Tod? Wie sieht es mit ExpandoObjects und dynamics aus?

Ich halte es auch für überzogen, an jeder Stelle auf Null zu prüfen, wenn es fachlich nicht sein kann, dass ein Objekt null ist - es aber technisch möglich ist (Beispiel Datenbank-Constraints, von denen die Entitäts-Ebene nichts mehr weiß).

Das Problem mit den non-nullable Types ist, dass dann oft ein Default, wie "0" für ints verwendet wird (oder der default(DateTime), der niemals sinnvoll ist), was semantisch schwierig wird. Genau deshalb wurde ja Nullable<> erst eingeführt.

Statische Analyse-Tools, wie z.B. Resharper prüfen schon heute Code gut genug, um "unnötige" NullRefs zu vermeiden. Also wenn man einfach einen Programmierfehler gemacht hat. Diese Fehler sind aus meiner Sicht sehr schnell gefunden und behoben, und nicht das Problem.

Das Posting wurde vom Benutzer editiert (28.08.2018 18:18).

Bewerten
- +
Anzeige