Eure besten Quellcode Kommentare...

[Der schöne Günther]

Delphi-Quellcode:

try
  (Gedöns)
except
  // Gibt schlimmeres
end;

[MaBuSE]

Zitat von Der schöne Günther:

// Gibt schlimmeres

Ja, eine Abmahnung zum Beispiel !

Ich hatte mal ein mittelgroßes Projekt (ca. 200 Forms) übernommen, bei dem das grundsätzlich so gemacht wurde.
Die Anwender hatten sich daran gewöhnt nach einer durchgeführten Aktion noch mal zu prüfen ob es geklappt hatte.

Die Mitarbeiter in der Abteilung wunderten sich nur, warum immer wieder falsche, unvollständige oder defekte Datenbankeinträge da waren.
Da wurde jeden Tag auf der Datenbank "repariert".

Als ich das Projekt übernahm, habe ich alle except end; gesucht und entfernt.

Ergebnis:
Die Anwendung war unbenutzbar. Im Sekundentakt sind Fehlermeldungen aufgetreten.
Bei jedem Create eines Formulars ist eine GPF aufgetreten. (Fehler in der Basisklasse)
Viele Copy & Pase Fehler. (Ein Mal falsch gemacht und immer wieder kopiert.)

Durch einige einfache Suchen & Ersetzen Aktionen waren mehrere 100 Fehler weg.

Die Anwender mussten umlernen. Keine Fehlermeldung = hat geklappt.
Dafür gabs ab und zu Fehlermeldungen, die automatisch geloggt und abgearbeitet wurden.
Nach ein paar Monaten war es dann "fehlerfrei".

Und 2 Leute arbeitslos, da sie nicht mehr den ganzen Tag die Datenbank reparieren mussten

Ich hasse Programmierer die so was verwenden

Delphi-Quellcode:

try
  ...
except
end;

FixInsight mahnt das zum Glück an.

Ich empfehle immer nur den "erwarteten" Fehler zu prüfen. Es kann ja immer etwas unerwartetes passieren

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
  end;
end;

...

begin
  Beispiel('Zwei');
end;

In unterem Beispiel wird ein String einer Integer Eigenschaft eines Objekts zugewiesen.
Der Programmierer hat daran gedacht, dass auch ungültige Zahlen wie z.B. "zwei" übergeben werden können.
Aber er geht davon aus , das MeinObjekt immer existiert. Was wenn MeinObjekt = Nil ist?
Das Beispiel unten würde dann zumindest eine Exception (oder GPF) werfen.

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    on E: EConvertError do
    begin
      // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
    end;
  end;
end;

...

begin
  Beispiel('Zwei');
end;

[himitsu]

TryStrToInt

Nacholgendes ist Beides das Gleiche,
auch wenn es kein schöner Code ist, außer da kommt wirklich "ständig" irgendwelcher Schrott, der aber niemanden interessiert.

Delphi-Quellcode:

i := StrToIntDef(S, 0);

try
  i := StrToInt(S);
except
  i := 0;  // S ist kein Integer
end;

Aber beim Debuggen wirst du schnell den Schuldigen erwürgen wollen, welcher Letzeres genommen hat, voallem wenn diese Funktion im Minutentakt mit Nichtintegern ausgeführt wird.

[Sherlock]

Oh, nichts überbietet ein gepflegtes

Delphi-Quellcode:

begin
  try
.
.
.
    Application.Run;
  except
  end;

end.

in der dpr...



Sherlock

[freimatz]

Nach dem "-->"

Code:

procedure TIsoPositionCmdTest.Test_InitData_CharacteristicID();
begin
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<referenceSystemCaseET>('DetermineReferenceSystemCase',
    rsc11EC);
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<TOrientationSet>
    ('AvailableToleranceZoneOrientationKinds', []);
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<TSourceElementsKindSet>
    ('AvailableToleranceZoneOrientationSources', []);

  { Puh: Mit dieser Zeile bringt man Wissen um die Implementiereung in den Test. Auch wenn von der Implementierung,
    von welcher hier die Rede ist, am Besten niemand etwas wüsste ;-).
    Der Test hier will eigentlich nur herausfinden, ob das richtige Element aus den beiden Elementfenstern für das
    zu tolerierende Element herangezogen wird. Diese Logik ist allerdings im InitData gut versteckt und eingebettet,
    so dass auch der Test dazu InitData aufrufen muss. 
--> InitData ist nun aber einer der schlimmsten Orte auf Erden. Das Ungemach, welches einem dort begegnen kann, 
    ist zu düster und umfangreich um es hier detailliert aufzuzeigen.
    InitData startet auch die Berechnung. Man versucht es zwar über ValidForCalculation zu verhindern, aber auch diese
    Methode ist unzureichend implementiert. Man geht dann aber wenigstens davon aus, dass dann das Merkmal in seinem
    Calculate schon jammert wenn was nicht passt. Würde es auch tun. Allerdings bedient sich das Positionsmerkmal dazu
    eines Services und der Success jenes Calculate ist im SetUpMocks mit true intialisiert. Darf halt nicht sein und
    deswegen hier das umstellen auf false.}
  m_ReferenceSystemGeneratorServiceMock.SetFunctionResult<IReferenceSystemCalculationResult>('Calculate',
    CreateReferenceSystemCalculationResult(false, identityMat4C, identityMat4C, '', sraUndefinedEC));

  Self.InitStatusDatabaseWithIdsAndDelegate('Kr1', 'Zyl1');
  CheckInitDataCharacteristicID();
end;

[Mavarik]

Zitat von MaBuSE:

Delphi-Quellcode:

try
  ...
except
end;

Ich empfehle immer nur den "erwarteten" Fehler zu prüfen. Es kann ja immer etwas unerwartetes passieren

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
  end;
end;

...

begin
  Beispiel('Zwei');
end;

Unter dem Strich hast Du natürlich zu 100% Recht. Also gibt es "eigentlich" nix was man hierzu erwidern kann, oder?

Die eigentlich Frage lautet : Was ist Dir wichtiger...?

Beispiel :

Gegeben sein eine Software die bei 5000 Kunden im Einsatz ist.
Gegeben sein eine Routine die bei diesen Kunden jeden Tag 100 Briefe ausdruckt...

Es gibt ein Softwareupdate das im Footer die Seitenanzahl ausgeben kann. In diese Routine hat sich ein Fehler eingeschlichen.

Dadurch wird die Seitenzahl nicht eingedruckt. Der try except end Abfänger verhindert eine Fehlermeldung...

Status : Alle Kunden sind glücklich - alle Briefe wurde gedruckt. Alle können "fehlerfrei" arbeiten!

Bei jedem Kunden 100x pro Tag ein Exception Fenster. Ist keine Option. Das würde nur die Hotline überlasten.
Von jeder Exception eine E-Mail (500.000 Stk.) ist auch keine Option.

Dann doch lieber einen Anruf von einem Kunden oder zwei (mehr merken es nicht, weil keiner die Neuerungsliste gelesen hat) der mitteilt, dass die Seitenzahl fehlt...

Also so pauschal kann man also doch nicht sagen ein "Try Except End" ist immer böse...

Gut, die Qualitätskontrolle hat versagt...

Aber wer hat schon für so etwas ein Test-Team oder einen Unittest - 30 Jahre alter Software?

Positiver Nebeneffekt - Die Kunden sagen: "Das ein oder andere Funktioniert noch nicht, aber dafür gibt es keine Exceptions in der Software..."

Mavarik

PS.: Oje... was werde ich dafür wieder an Kommentaren ernten..

[himitsu]

Es geht vorallem um die leeren Try-Except, also wo im Fehlerfall rein garnichts gemacht wird, bzw. wo der Fehler fahrlässig nicht/falsch behandelt wird.

Fehler abfangen und loggen ist auch eine Behandlung.



zu deinem Beispiel:
* fehlt nur die Seitenzahl, aber das dokument kommt raus, dann isses OK
* wird dennoch die "Zahl" geschrieben, aber mit einem falschen Wert, dann wird es schon problematischer
* wird garnichts mehr gedruckt, andere Teile fehlen im Ausdruck oder sind dadurch falsch, dann wäre es nicht nett, wenn der User die Fehlermeldung nicht bekommt

[JasonDX]

Ich würde zudem argumentieren dass die Qualitätsprüfung insb. dann fehlschlägt, wenn kein offensichtlicher Fehler auftritt. Wenn denen eine Exception um die Ohren fliegt, wird das Update nicht rausgehen. Weil aber Fehler geschluckt werden, sind Kleinigkeiten falsch die den Testern nicht auffallen, und der Kunde bekommt die Bananensoftware zum selbertesten.
Aber gut, jeder darf selbst die Qualität seiner Software bestimmen.


(was schreibst du dann eigentlich in deine Patch-/Update-Beschreibungen? "Druckt Seitenanzahl - vielleicht"?)

[MaBuSE]

Zitat von Mavarik:

Unter dem Strich hast Du natürlich zu 100% Recht. Also gibt es "eigentlich" nix was man hierzu erwidern kann

Das lass ich jetzt mal so stehen ;)

Zitat von Mavarik:

Die eigentlich Frage lautet : Was ist Dir wichtiger...?
...
Es gibt ein Softwareupdate das im Footer die Seitenanzahl ausgeben kann. In diese Routine hat sich ein Fehler eingeschlichen.
Dadurch wird die Seitenzahl nicht eingedruckt. Der try except end Abfänger verhindert eine Fehlermeldung...

Mir wäre wichtiger, dass der Fehler schnellstmöglich gefunden und behoben wird, statt dass sich viele nicht gefundene Fehler anhäufen und nie von dem Entwickler behoben werden, da er nichts davon weiß.

Wenn Du nicht in der Lage bist Deine Software (wenigstens einigermaßen) zu testen, solltest Du von Deinen 5000 Kunden 25 fragen, ob sie an einen Beta Test teilnehmen möchten.
Im Beta Test kannst du schnell neue Versionen ausrollen und die Kunden sind oft dankbar, das sie schon die neuen Funktionen nutzen können.

Langfristig hast Du aber viel mehr zufriedene Kunden (, bei denen die Seitenzahlen richtig geduckt werden;)
Und diese Kunden haben dann auch zufriedene Kunden, da auf ihren Schreiben keine falschen Seitenzahlen gedruckt wurden. ;)


Verstehe mich nicht falsch. Es spricht nichts dagegen Fehler zu klassifizieren und "unwichtige" Fehler "nur" zu loggen und den Anwender nicht damit zu belästigen.
Aber durch das fehlende on E: Fehlerklasse oder das böse try ... except end; darauf zu verzichten nicht klassifizierte also unbekannte Fehler zu entdecken, finde ich fraglich.

Ich möchte beim Autofahren auch erfahren, wenn ein unbekanntes Problem bei meinen Bremsen auftritt.
Unwichtige "bekannte" also klassifizierte Fehler interessieren mich hingegen nicht.
Das erwarte ich von den Programmierern der Software in meinem Auto.

[Mavarik]

Zitat von MaBuSE:

Ich möchte beim Autofahren auch erfahren, wenn ein unbekanntes Problem bei meinen Bremsen auftritt.
Unwichtige "bekannte" also klassifizierte Fehler interessieren mich hingegen nicht.

Möchtest Du auch, dass durch einen Fehler im "Bremsen Sensor abfrage Programm" Dein Auto jedes mal stehen bleibt und der Motor aus geht?

Nee, Spaß beiseite - schon klar worum es Dir geht... (Ist auch der falsche Thread für diese Diskussion)