Delphi merkt nicht wenn ein case-Statement vollständig ist, oder?

[Der schöne Günther]

Ich bekomme bei folgendem

Delphi-Quellcode:

case

-Statement eine Warnung, dass eine Variable "möglicherweise" nicht initialisiert sein könnte:

Delphi-Quellcode:

type
   TEnum = (a, b, c);
var
   myEnum: TEnum;
   value: Byte;
begin
   myEnum := TEnum.a;
   case myEnum of
      TEnum.a:   value := 10;
      TEnum.b:   value := 20;
      TEnum.c:   value := 30;
   end;
   WriteLn(value); // W1036"might not have been initialized"
   // altough the case statement is exhaustive
end.

Bei C++ ist der Compiler schlau genug:

Code:

enum Enum {a, b, c};

int main(int argc, char **argv) {
   Enum e = Enum::b;
   char c;
   switch (e)
   {
      case Enum::a:
         c = 1;
         break;
      case Enum::b:
         c = 2;
         break;
      case Enum::c:
         c = 3;
         break;
   }   

   std::cout << c;
   return NO_ERROR;
}

Bei Sprachen wie Swift oder Rust bricht der Compiler mit einem Fehler ab, wenn ein match-Statement nicht vollständig ist.

Delphi bekommt von all dem aber nichts mit, und redet sich damit raus, dass es "möglicherweise" undefiniert sein könnte.
Zumindest in 10.0 Seattle.

Ist das in einer aktuellen Delphi-Version immer noch so?

[himitsu]

Jupp, denn Delphi weiß, dass in deinem Enum noch 253 weitere Werte sein können.

z.B.

Delphi-Quellcode:

myEnum := TEnum(123);

Sowas kannst du nur ausschließen, wenn bei Zuweisung an diese Variable der Wertebereich geprüft wird,
und wenn man sämtliche Fehler ausschließen kann, z.B. böse Casts, fehlgeleitete Pointer, Buffer-Overflow, Häcker/Würmer/Viren, usw.

[Der schöne Günther]

Oder es heißt dass der Teil der die Fehlermeldungen generiert gar nichts mehr von Enums weiß, da er nur noch mit blanken Zahlentypen arbeitet.

Oh mann... 😕

[BerndS]

Ich füge dem case oft noch ein else hinzu, wobei dann im Debug eine Exception ausgelöst wird und im Release passiert nichts.
Kommt später was zur Aufzählung hinzu, so erinnert mich die Exception dann, das noch was fehlt.

[bernau]

Zitat:

Zitat von BerndS (Beitrag 1498595)

Ich füge dem case oft noch ein else hinzu, wobei dann im Debug eine Exception ausgelöst wird und im Release passiert nichts.
Kommt später was zur Aufzählung hinzu, so erinnert mich die Exception dann, das noch was fehlt.

Bei mir auch. Genau so.

[himitsu]

Ich werfe die Exceptions immer, egal ob Debug oder Release.
Oder setze im Else die Variable auf NIL, was eh sein muß, weil ja sonst der Compiler von nicht-initialisierten Variablen schwafelt.

Abgesehn da, wo eh immer nur ein Teil behandelt wird.

[Rollo62]

Ich setze IMMER ein "else", weil man ja schnell mal einen Typen ergänzt und dabei ein case statement vergisst.
Das macht es dann "sichtbarer", fehlertolerant und die Fehlersuche ist dann viel leichter als wenn man sich auf Compiler-Automatismen verlassen würde.
Deswegen finde ich das Warning auch gut und richtig.

[Mavarik]

Zitat:

Zitat von Der schöne Günther (Beitrag 1498589)

Bei Sprachen wie Swift oder Rust bricht der Compiler mit einem Fehler ab, wenn ein match-Statement nicht vollständig ist.

Oh wie gruselig ist das den?

Wieso soll ich den immer alles definieren? Vielleicht will ich mit der Case ja nur Teile prüfen...

Oder übersehen ich da etwas?

Mavarik

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1543267)

Wieso soll ich den immer alles definieren? Vielleicht will ich mit der Case ja nur Teile prüfen...

Oder übersehen ich da etwas?

Nein, da übersiehst du nichts. Aber das Problem ist dabei, dass solcher Code auch fehleranfällig ist. Denn du merkst ja gar nicht, wenn ein Enum erweitert wird und der Fall nicht behandelt wird. Wenn mehrere Entwickler an einem Projekt arbeiten, passiert so leicht ein Fehler.

Genau aus diesen Gründen wird das in Rust und anderen Sprachen geprüft und genau deshalb werden diese an sicherheitsrelevanten Stellen gerne eingesetzt.

Für den von dir beschriebenen Fall kann man z.B. mit if-Statements arbeiten.

[TomyN]

Ich denke, ein 'Defaultwert' ist immer wichtig. Ob man den jetzt im else setzt oder (was ich inzwischen, auch weil ich beginne die Exit Anweisung einzusetzen, gerne mache) vor der Unterscheidung erstmal einen Wert zuzuweisen, ist in meinen Augen (fast) egal. Beim Else offenbart sich ein Fehler (d.h. eine 'unerwartete' Bedingung) eher, was in der Entwicklung wünschenswert, beim Kunden aber ggf. kontraproduktiv ist.