Niemals Null zurückgeben - Clean Code Tipps #1

preview_player
Показать описание
Warum solltest Du niemals null zurückgeben? Egal ob C#, Java, Python, Java Script, Typescript oder C++ - in allen Sprachen kann Null in Methoden zurückgegeben werden? Aber sollte man das machen? Wir gucken uns im ersten Programmiertipp an, warum null niemals zurückgegeben werden sollte und zeigen auch warum.

▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬

Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)

▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Рекомендации по теме
Комментарии
Автор

Eigentlich ein guter Tip, aber null hat halt nicht nur eine syntaktische Bedeutung sondern auch eine semantische (Unterschied zwischen leerem Wert und gar kein Wert) weshalb es nicht immer möglich ist niemals null zurück zu geben.
Java hat dafür seit JDK 8 aber auch eine sehr schöne Möglichkeit: Optional<T>. Damit markiert man explizit das der Rückgabe-Wert auch null sein kann und der Aufrufer muss mit den Optional erstmal unboxen bevor er ihn verwenden kann. In .NET bietet sich hierfür der ??-Operator an und die entsprechende nullable Annotation am Rückgabewert.

grimfistgaming
Автор

Kommt absolut auf die Datenstrukturen die man nutzt, die Komplexität des Programms und auf die anvisierte Effizienz/Performanz des Programms an. Manchmal ist es sogar völlig erwünscht, dass Null zurückgegeben bzw. ein Feld im 2DArray damit belegt wird. Ich hatte mal exakt diesen Fall und da habe ich Null zu schätzen gelernt.^^

ParalyticAngel
Автор

Hallo David,

ich denke Du solltest diese Video einmal überarbeiten.

In vielen Fällen ist die Nullrückgabe in .Net 6 gesichert, da die Null Verweistypen direkt darauf verweisen.
Es ist ja dann direkt zu erkennen dass der Rückgabewert von "string?" null sein kann.
Selbst VS in Verbindung mit dem StyleCorp mäkelt diesen Zustand sofort an.

Daher sind solche Methoden doch sofort zu erkennen und entsprechend zu handeln!?

Oder siehst Du das anders.

LG
Marcus

marcusreinicke
Автор

Was für ein Quatsch. Wenn die ersatzweise Exception für den direkten Aufrufer bestimmt ist kann man dem auch null zurückgeben, das ist einfacher zu handhaben.

OlliS
Автор

und wie soll die Exception sein? NotFoundEcxception? soll jede function eigene NotFoundXxxxException defenieren? und woher soll der Entwicler wissen wie diese Exception für jede Function heisst?

begelmanleonid
Автор

Danke für die Inspiration David. Allerdings sind Exceptions langsam. Der Lösungsteil des Videos ist leider ein wenig kurz ausgefallen ;-)
Exceptions müssen auch gefangen werden im Client. Klar geht das gestaffelt, aber kein grosser Unterschied?

JackalFPV
Автор

Es kommt hier sehr stark auf die sprache die verwendet wird an. in strikteren sprachen kann man null als erwarteten return mit angeben. dann ist es einem unmöglich ausversehen auf ein "verkleidetes" null zuzugreifen.

wenn jedoch wie in deinem beispiel null so tut als sei es der rückgabewert, dann unterstütze ich auch deine aussage da es sehr intransparent ist und weniger wenn nicht gar nicht benutzt werden sollte

david.baierl
Автор

Ich finde die Aussage "niemals" falsch, aber den Hinweis auf OrDefault gut. Wenn man Libraries schreibt, dann ist die niemals Null Herangehensweise sicher nicht verkehrt. Ich würde aber kein Gesetz daraus machen. Besonders seit C# nullable types unterstützt ( int? oder User? z. B.)

ignisAnimus
Автор

Stichwort "Null avoidance".

Wie anhand der Kommentare ersichtlich ist, hat sich das Get/TryGet Muster, welches eben auch aus dem C#-Framework bekannt ist, hier bei einigen durchgesetzt - so auch bei uns.
GetByXY liefert immer einen Datensatz zurück und wirft im negativen Fall eine mit den entsprechenden Informationen bzgl. Suchkriterien.
TryGetByXY liefert im Gegensatz einen boolean-Wert und das Model als out-Parameter, sodass der Aufruf schön und sauber (in Verbindung mit einem if-Statement) durchgeführt werden kann bzw negiert wird und darin eine saubere UI-Fehlermeldung erzeugt werden kann.

gruaba
Автор

Man könnte in der Klasse Person aus dem Beispiel auch eine statische Instance Nobody analog zu string.Empty und diese zurückgeben, wenn man nichts findet. Auf diese könnte gefahrlos zugegriffen werden und ihre Methoden machen dann "nichts".

Humanrebel
Автор

Könnte man in diesem Fall der null Objekt Muster benutzen?

schulzyyy
Автор

Jein...
Es ist durchaus legitim NULL als Rückgabewert zu verwenden. Seit C# 8 werden null coalescing (??) Operatoren und seit C# 6 der NULL bedingte Operator (?.) als Shortcircuit operator eingeführt. Damit kann vorzüglich und sicher mit NULL programmiert werden. Wenn das so evil wäre, dann hätte MS das wohl kaum in die Sprache aufgenommen. Ok, dies bedingt ein spezielles Vorgehen bzw. sorgfältiges Design der Klassen, aber gerade in Verbindung mit DSLs kann dies sehr klaren Code ergeben.
Von endlosen try-catch Blöcken halte ich persönlich gar nix. Diese sind nur bei elementaren I/O Fehlern sinnvoll (DB Connection lost usw.) imho

thomasschroter
Автор

Interessant. Gleich mal checken wie es bei uns gemacht ist.

andreweinert
Автор

I see the pattern of findByIdOrThrow, also die Annahme das ein nicht finden, kein fehler ist, sondern ein ganz normaler Fall der eintreten kann

tobiasnickel
Автор

Anstatt Exceptions könnte man hier auch eine Maybe Monade verwenden.
Dadurch muss sich der Aufrufer damit auseinandersetzen, dass die gesuchte Person möglicherweise nicht existiert.

stefan
Автор

Deshalb mag ich das Nullable-Reference-Feature bin C# 😃
Oder der ?.-Operator, wie auch immer der heißt.

In den meisten Fällen, wo es möglich ist, nutze ich statt Null das TryXYZ-Konzept mit bool-Rückgabe und out-Parameter. Das bedeuteten dann zwar auch mehr Komplexität, allerdings kommt man als Aufrufer nicht mehr drum herum.
Oder (selten) eine Try-Methode, bei der das "Try" zeigt, dass auch Null zurückgegeben werden kann, da mir ein "OrDefault" den Namen zu lang macht.

Oder - wenn es das Vorhaben zulässt - ein NullObject nach dem gleichnamigen Pattern.

Palladin
Автор

Wer es sich bei Exceptions einfach machen will, nutzt große try / catch Blöcke. Gewonnen hat man dadurch rein gar nichts. Bei Java sind Exceptions wahrscheinlich sinnvoll, ansonsten halte ich nicht viel davon außer bei Hardware-Fehlern.

dennismarks
Автор

Ich stimme mit vielen Aspekten der Clean-Code-Religion nicht überein.
Exceptions vermeide ich wegen des Overheads, wo es nur geht. Vor allem ist eine Exception nicht dazu da, einen Fehler auf einer einzigen Stufe anzuzeigen. Interessant werden Exceptions erst dann, wenn sie dazu bestimmt sind, über mehrere Ebenen des Stacks gereicht und zentraler aufgefangen zu werden.

Es ist auch kein Argument, daß ein trantütiger Programmierer die Null-Prüfung vergessen könnte. Genauso kann er auch das Auffangen der Exception vergessen, und es führt zu unerwarteten Programmabbrüchen. Und wenn ich den Beginn eines Musters im String suche, muß ich auch damit rechnen, daß mein Muster gar nicht gefunden werden kann und kann mich nur extrem selten darauf verlassen, daß es enthalten sein muß - nur in einer in sich geschlossenen Logik, und wenn performancekritische Stellen einer zusätzlichen Prüfung widersprechen. Ob jetzt auf null, false oder -1 etc. geprüft wird, spielt auch keine Rolle. Bei null ist man nur so kritisch, weil vor allem von Anfängern gerne ungeprüft auf Members von Instanzen zugegriffen wird.

Die Empfehlung ist auch etwas veraltet aus Zeiten, in denen es noch keine null coalesing operators gab. Mit dem Operator wird der Code sogar weit weniger komplex als Exception-Handling und die ganzen anderen Workarounds.

pinkeHelga
Автор

Hättest den Titel auch "Die DüsterException" nennen können ;)

janz.
Автор

Auch in PHP sollte man Exceptions werfen. Ja, die gibt es dort. Es gibt in PHP alles, was eine professionelle Programmiersprache ausmacht. Sogar DI Container. Nur mal zur Aufklärung.

bernhardd