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..