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

[Mavarik]

Zitat von Der schöne Günther:

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 von Mavarik:

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.

[Uwe Raabe]

Ich persönlich hätte auch etwas gegen einen Compilerfehler bei unvollständigem case x of . Es kommt schon häufiger vor, dass ich vorab per if x in [..] then eine Bereichsprüfung mache und dann mit einem case x of die verschiedenen (in diesem Bereich möglichen) Fälle auseinandernehme.

Gäbe es generell einen Fehler bei einem unvollständigen case-Statement wäre die else-Syntax ja auch überflüssig.

Nichtsdestotrotz gibt es bei mir auch reichlich case-Konstrukte, bei denen im else-Zweig eine EProgrammerNotFound Exception geworfen wird. Die bereits anderswo erwähnten Unit-Tests sind dabei schon sehr hilfreich.

[jaenicke]

Zitat von Uwe Raabe:

Gäbe es generell einen Fehler bei einem unvollständigen case-Statement wäre die else-Syntax ja auch überflüssig.

Mit else sollte kein Fehler kommen, das sehe ich auch so. Ich setze das else aber meistens nur, um einen Fehler durch fehlende Behandlung neuer Elemente abzufangen. Das wäre dann oft unnötig.

[Rollo62]

Zitat von Uwe Raabe:

... if x in [..] then eine Bereichsprüfung mache ... und dann case x of

Gibt es denn einen Vorteil, außer der vielleicht besseren Lesbarkeit oder Zusammenfassung von Gruppen, das vorab mit if x in [..] zu machen?
Z.B. Performance, oder so?

Ich meine ein "case x of" sollte immer am performantesten sein und das zusätzliche "if x in" überflüssig machen.
Ok, bei großen Strukturen wird es unlesbarer ...

[Uwe Raabe]

Das hat eigentlich ganz andere Gründe. Nehmen wir z.B. einen Enum-Typ, der positive und negative Elemente enthält. Bei positiven bzw. negativen Werten sind spezifische Code-Teile auszuführen, die teilweise vom genauen Wert unabhängig sind, während andere Teile vom exakten Wert abhängen:

Delphi-Quellcode:

type
{$SCOPEDENUMS ON}
  TRating = (undefined, Perfect, OK, Acceptable, NotGoodEnough, Bad, TotalShit);

  TRatingHelper = record helper for TRating
    procedure HandleIncompleteCase(Rating: TRating);
  end;

procedure TRatingHelper.HandleIncompleteCase(Rating: TRating);
begin
  raise EProgrammerNotFound.Create('unhandled case for TRating: ' + TRttiEnumerationType.GetName(Rating));
end;

const
  cRatingPositive = [TRating.Perfect, TRating.OK, TRating.Acceptable];
  cRatingNegative = [TRating.NotGoodEnough, TRating.Bad, TRating.TotalShit];

procedure HandleRating(Rating: TRating);
begin
  if Rating in cRatingPositive then begin
    // Handle positive rating part 1
    ...
    // Handle specific rating
    case Rating of
      TRating.Perfect: ...;
      TRating.OK: ...;
      TRating.Acceptable: ...;
    else
      HandleIncompleteCase(Rating);
    end;
    // Handle positive rating part 2
    ...
  end
  else if Rating in cRatingNegative begin
    // Handle negative rating part 1
    ...
    // Handle specific rating
    case Rating of
      TRating.NotGoodEnough: ...;
      TRating.Bad: ...;
      TRating.TotalShit: ...;
    else
      HandleIncompleteCase(Rating);
    end;
    // Handle negative rating part 2
    ...
  end
  else begin
    // Handle undefined rating
    ...
  end;
end;

[Rollo62]

Zitat von Uwe Raabe:

Das hat eigentlich ganz andere Gründe.

Ah ja, das hatte ich mir schon gedacht.
Danke, das ist ein sehr schönes Beispiel

Aber trotzdem, ist es am Ende nicht fast das gleiche Ergebnis wie:

Delphi-Quellcode:

// Handle specific rating
    case Rating of
      //Positive rating
      TRating.Perfect: ...;
      TRating.OK: ...;
      TRating.Acceptable: ...;

      //Negative rating
      TRating.NotGoodEnough: ...;
      TRating.Bad: ...;
      TRating.TotalShit: ...;
    else
      HandleIncompleteCase(Rating);  //<== OK, hier kann man nicht genau in Positive/Negative unterscheiden
                                     //    Aber Du kommst ja trotzdem auf den richtigen, "falschen" case.
                                     //    Wenn das "if x in" nicht passt, dann muss es auch nicht für "case x of" passen.
     
    end;

type
    cRatingPositive = [TRating.Perfect..TRating.Acceptable];  // Wenn man es so definieren könnte, dann vielleicht.

So richtig sehe ich den Mehrwert noch nicht.
Ist das dann nicht eher ein Fall für ein Enum Set, mit allen seinen mathematischen Möglichkeiten?