Handling von Fehlern, Warnungen und Hints

**SubData**

Pack an das Ende der Unit ein WARNINGS ON, dann dürfte es wieder stimmen.

Zitat von MaBuSE:

Das ist auch der Grund warum ich mir in Fragen an CodeGearThread gewünscht habe, dass man einzelne Warnungen über die Nummer und nicht nur über die Gruppe ausschalten kann. {$WARN W1035 OFF} // Warnung "W1035 Rückgabewert der Funktion <name> könnte undefiniert sein" unterdrücken.

SEHR schöne Idee!

**MaBuSE**

Zitat von SubData:

Pack an das Ende der Unit ein WARNINGS ON, dann dürfte es wieder stimmen.

Es sei denn ich möchte aus irgendwelchen Gründen alle Warnungen des Compilers mit der DCC32 Compileroption ausschalten.
Das würde damit rückgängig gemacht werden

Hallo,

meine Devise:

Wenn Programme rausgehen an den Kunden, haben sie keine Hinweise und Warnungen mehr (ausser Plattform, da gibt's halt nur Windows).

Bei Programmen für den eigenen Bedarf bleiben Hinweise und Warnungen nur dann über, wenn ich geprüft habe und ruhigen Gewissens entscheiden kann, für diesen Job ist das okay, das sind dann aber in der Regel nur irgendwelche Tools und Helferlein für den persönlichen Bedarf oder Spielereien für zu Hause.

@MaBuSE, was machst Du denn da in Deinem Beispiel? Okay, ich schreibe in der Regel nur kaufmännische Software, da brauch ich sowas nicht und habe keine entsprechenden Probleme

Stephan

**alzaimar**

Ich schalte in den Hack-Units am Anfang und nach der Uses-Klausel die Warnungen AUS und am Ende wieder EIN. Das funktioniert.

Das hier gepostete Beispiel ist mir zu konstruiert. Wer solche Konstrukte verwendet, darf die Warnungen getrost ignorieren, ihm ist eh nicht mehr zu helfen.

**Hansa**

Zitat von alzaimar:

Ich schalte in den Hack-Units...darf die Warnungen getrost ignorieren, ihm ist eh nicht mehr zu helfen.

In den Hack-Units würde es mich eher stören, keine Warnungen zu sehen.

Ich werde jeden Tag mehrmals gewarnt, dass es noch ein FILE OF gibt. Das ist mir vorerst egal, aber wenn ein Dritter mit einem Programm arbeiten muss, dann stelle ich sicher, dass keine Eventualitäten ausgeliefert werden. Das bedeutet in letzter Konsequenz dann eben, die Warnungen als Error zu interpretieren und fertig. Das kann nicht nach dem Motto laufen "es compiliert, wir können ausliefern". 8)

Zitat von Hansa:

Das kann nicht nach dem Motto laufen "es compiliert, wir können ausliefern". 8)

Exakt so sehe ich das auch. Alles Andere halte ich für inakzeptabel.
Vermeintlich fehlerfreie Software gibt es genug und damit ärgern wir uns alle rum.
Da müssen wir es nicht auch so machen.
Es ist zwar schön, wenn man 'nen Servicevertrag hat, aber noch schöner ist es, wenn der nicht in Anspruch genommen werden muss, weil keine Probleme auftreten.

Stephan

**uligerhardt**

Zitat von Dezipaitor:

Nein, natürlich nicht. Aber wenn es sowas wie {$WARN UNDEFINED_RESULT OFF} und {$WARN UNDEFINED_RESULT DEFAULT} gegeben hätte, dann wären nun über 3000 Funktionen, die semantisch korrekt einen Rückgabewert liefern, ohne diese Warnungen. Dadurch würden Warnungen aufgedeckt, die auch stimmen.

Es gibt doch {$WARN NO_RETVAL OFF}. Oder steh ich auf dem Schlauch und du meinst was Anderes?

**MaBuSE**

Zitat von nahpets:

@MaBuSE, was machst Du denn da in Deinem Beispiel? Okay, ich schreibe in der Regel nur kaufmännische Software, da brauch ich sowas nicht und habe keine entsprechenden Probleme

Das Beispiel (

Beitrag 58) sollte nur zeigen um was es eigentlich bei der Diskussion um den

Beitrag 34 in diesem Thread geht.
Dezipaitor hatte ein Stück Sourcecode geposted, über das hier diskutiert wird.

Ich habe nur versucht den Quelltext zu erklären.

Bzw. zu zeigen warum mit dem asm JMP [_AddSecurityPackageW] end; das Result (EAX) gesetzt wird.

**MaBuSE**

Zitat von uligerhardt:

Zitat von Dezipaitor:

Nein, natürlich nicht. Aber wenn es sowas wie {$WARN UNDEFINED_RESULT OFF} und {$WARN UNDEFINED_RESULT DEFAULT} gegeben hätte, dann wären nun über 3000 Funktionen, die semantisch korrekt einen Rückgabewert liefern, ohne diese Warnungen. Dadurch würden Warnungen aufgedeckt, die auch stimmen.

Es gibt doch {$WARN NO_RETVAL OFF}. Oder steh ich auf dem Schlauch und du meinst was Anderes?

Stimmt, Du hast Recht.

Vielleicht hätte ich noch mal mein eigenes Tutorial lesen sollen,

dann hätte ich Dezipaitor auch selbst drauf hinweisen können.

[equote="Im Tutorial (

http://www.delphipraxis.net/internal...t.php?t=115445 ) steht:"]{$WARN NO_RETVAL ON}
Warnung: Rückgabewert der Funktion '<Element>' könnte undefiniert sein
Diese Warnung wird angezeigt, wenn dem Rückgabewert einer Funktion nicht in jedem Codepfad ein Wert zugewiesen wurde.
Die Funktion könnte auch ausgeführt werden, ohne dass der Rückgabewert zugewiesen wird.
Die Lösung besteht darin, sicherzustellen, dass der Rückgabewert in jedem möglichen Quelltextpfad zugewiesen wird. [/equote]

Danke

**Dezipaitor**

So langsam wird das Thema unübersichtlich und ich blicke es auch nicht mehr. Jetzt habe ich extra das Tutorial genau angeschaut, aber diese Direktive glatt übersehen.

Also Freiwillige vor!

Die JEDI API gibt es seit Delphi 5 (und früher?), als man die Warnungen noch nicht abschalten konnte. Daher steht es nicht drin.