AndAlso hilft dir hier.

Wenn die erste Bedingung nicht zutrifft, wird die 2. erst garnicht mehr geprüft, somit keine Exception wenn Liste is Nothing beim Test ob Count > 0

Der Unterschied zwischen And und AndAlso/Or und OrElse
If Not _ListOfHaltungWithHardSplit Is Nothing -> If _ListOfHaltungWithHardSplit IsNot Nothing; das schlägt inzwischen auch VS vor.

Nunja, mir zeigte VS diesen Änderungsvorschlag nicht an. Warum ist denn If _ListOfHaltungWithHardSplit IsNot Nothing deiner Meinung nach besser? If finde If Not... besser lesbar, als wie If var IsNot , weil das Not sofort am "Anfang der Bedingung" sichtbar ist. Finde ich dann besonders gut, wenn mehrere Bedingungen in einer Zeile verknüpft sind.

Tja, Geschmackssache. Ich lager v.a. komplexe Bedingungen in ne Funktion aus, damit ich mir gar nicht den Ausdruck im Gesamten anschauen muss, sondern über den kompakten Funktionsnamen sehe, was da geprüft wird.

jan99 schrieb:

Kann man diese beiden If-Statements irgendwie zusammenfassen?

Takafusa schrieb:

If Not _ListOfHaltungWithHardSplit Is Nothing AndAlso _ListOfHaltungWithHardSplit.Count > 0 Then

Da müsste man doch auch einfach mit einem nullbedingten Operator arbeiten können.

petaod schrieb:

nullbedingten Operator

Dachte den gibt es nicht in VB. Aber praktisch das es das doch gibt. Ich sollte mir mal die neuerungen der letzen Jahre anschauen, da hat sich wohl doch noch was getan.

LeiderLeiderLeider funktioniert das nicht.
VB hat da einen Bug - zumindest neulich gehabt. Obwohl der nullbedingte abbrechen soll wird dennoch .Count abgerufen und Exception.
Oder ist das inzwischen gefixt?

nö, klappt problemlos

Sorry - der Bug war komplizierterer Natur:

Und ist leider immer noch da

in c#, mit && verhält sich das ok.

Vollzitat des direkten Vorposts an dieser Stelle entfernt ~VaporiZed

Ist kein Bug, steht auch so in der Doku zu Nullable Types in VB.NET. VB konstruiert für die Expression items?.Count > 0 ein Nullable(of Boolean) was halt wegen der Liste, die Null ist, zu Null bzw. [Nothing] evaluiert.
Aus der Doku:

AndAlso and OrElse, which use short-circuit evaluation, must evaluate their second operands when the first evaluates to Nothing.

Und da du in deinem Beispiel auf ein Element der Liste zugreifst, bekommst du die NullReference-Exception.

Schade, dass sie das nu auch noch festgeschrieben haben, anstatt es zu fixen.
Wie gesagt in c# verhalten sich die entsprechende short-circuit-evaluationen wie man es ich finde erwarten sollte:


Deine Erklärung verstehe ich nicht.
Warum muss der zweite AndAlso-Operand ausgewertet werden, wenn der erste bereits Null ergibt? (also mal abgesehen davon, dasses inne Doku steht)
Wirds in c# ja auch nicht.

Ich (und c# auch), wir verstehen den AndAlso-Operator als Kurzschreibe dieser Konstruktion:Dass diese Äquivalenz nicht besteht ist imo hanebüchen.
Und ?. + AndAlso wie gezeigt zu verwenden wäre ja auch sinnig und elegant.

Wohingegen den zweiten Operanden auszuwerten, obwohl der erste bereits nicht True ergibt - das steht doch im krassen Widerspruch zum Sinn von AndAlso.
Also zu welchem Zweck ist AndAlso denn erfunden worden? Wenn nicht dazu, den zweiten Operanden auszuwerten sich zu ersparen.

ErfinderDesRades schrieb:

Wirds in c# ja auch nicht

Der Compiler in C# macht andere Sachen als der von VB.NET. Das wird deutlicher, wenn man sich folgendes genauer anschaut


IL:




IL


In VB.NET hat das Ergebnis aus dem Ausdruck items?.Count > 0 den Datentyp Nullable(Of Boolean) (Man muss sogar den Boolean als Nullable deklarieren, sonst kompiliert das Programm nicht) - C# evaluiert diesen allerdings als Wert und somit false.

Wenn man sich den IL-Code für folgendes Beispiel genauer anschaut, sieht man, dass intern für den ersten Ausdruck ein Nullable(Of Boolean) erzeugt wird. (IL_001A)


IL:

ErfinderDesRades schrieb:

bereits nicht True ergibt

Der Ausdruck ist aber auch nicht False, sondern Null. Das wird wahrscheinlich der Grund sein, warum dann der zweite Ausdruck ebenfalls geprüft werden muss.

Ganz logisch/konsequent ist das von Mikrosaft aber nicht. Weil: Wenn ich in VB ein Nothing mit nem fehlerbehafteten Ausdruck per AndAlso kombiniere, wird's trotzdem ohne Anstalten zu False "short-cicuited". Dementsprechend liegt's nicht an AndAlso/OrElse an sich. Selbst wenn ich die Zielvariable als Boolean? definiere.

Wenn man sich das ebenfalls mal im IL-Code anschaut, erkennt der Compiler, dass Nothing AndAlso ... wahrscheinlich immer False ist und Optimiert das entsprechend.

IL:


Während er im oberen Beispiel den Ausdruck wirklich auswerten muss, weil die Liste ja auch nicht Null sein könnte.

ISliceUrPanties schrieb:

Der Ausdruck ist aber auch nicht False, sondern Null. Das wird wahrscheinlich der Grund sein, warum dann der zweite Ausdruck ebenfalls geprüft werden muss.

Bei dreiwertiger Boolscher Algebra - wie sie für Nullable<bool> gültig ist - spielt es keine Rolle, ob Null oder false.
Beides gilt in 3-wertiger Logik als "Nichtzutreffend" .
Mein Beispiel aus post#12, mit dem If im If - Then zeigt, dass das auch funktioniert.

AndAlso aber ist unsinnig implementiert, wenn es bei "Nichtzutreffend" des ersten Operanden den zweiten trotzdem auswertet.

Hier nochmal ein gesonderter Test des Debakels:

Und - klar, wenn man IL guckt wird man Unterschiede finden zw. c# und vb.
Weil in c# funktionierts ja.

ErfinderDesRades schrieb:

AndAlso aber ist unsinnig implementiert, wenn es bei "Nichtzutreffend" des ersten Operanden...

Ich würde nicht sagen, dass AndAlso "unsinnig" implementiert ist, sondern es ist ganz klar nach der VB Spezifikation implementiert. Dort steht für "Short-circuiting Logical Operators"

​If the first operand in an AndAlso operation evaluates to False or returns True from its IsFalse operator, the expression returns its first operand. Otherwise, the second operand is evaluated and a logical And operation is performed on the two results.

Und Null ist nunmal nicht False. (Wobei man darüber sichlich gut streiten kann) Folgende Links sind zu dem Thema noch recht interessant: github.com/dotnet/vblang/issues/478 und github.com/dotnet/csharplang/issues/871.

Das eigentliche Problem für mich ist hier nicht der AndAlso-Operator, sondern, wenn wir bei deinem Beispiel bleiben, dass der VB-Compiler aus items?.Count > 0 ein Nullable(Of Boolean) erzeugt, welches halt null ist.

Das sehe ich wiederum nicht als das eigentliche Problem. Das ist genau, wie der NullDependent-Operator ?. sinnvollerweise definiert ist, sowohl in c# als auch in vb.
check ma die b-Datentypen bei:und Was soll er da auch sonst draus machen, wenn kein Nullable(Of Boolean)?

Ansonsten sagte Ich ja schon: Das vb-Fehlverhalten wird nicht dadurch richtig, dass sie es in die Dokumentation schreiben.
Es ist und bleibt Unfug, wenn bei AndAlso der zweite Ausdruck ausgewertet wird, obwohl der erste nicht True ist.

Wenn sie die Sprache so spezifiziert haben, dann ist eben die Spezifikation auch schon Unfug.

ErfinderDesRades schrieb:

dann ist eben die Spezifikation auch schon Unfug

Dann solltest du dich hier github.com/dotnet/vblang/issues mit einem Vorschlag zur Verbesserung von AndAlso und Null einbringen, um die Sprache weiter zu entwickeln
Sei es, wie es ist. Ich denke, das Thema ist dann ja jetzt auch durch. Es wurde genug auf Doku und Spezifikation hingewiesen.