Handling von Fehlern, Warnungen und Hints

[Phoenix]

Ist es ja. Und die Standard-Einstellungen ist ja auch der bisherige Stand. Nur kann man eben - so man denn will - einschalten dass Warnungen als Fehler behandelt werden. Ich habs an (schon seitdem Andreas das in den DDevExtensions drin hat) und bin happy damit

[alzaimar]

Wer Hinweise und Warnungen grundsätzlich ignoriert, wird nie ordendliche und robuste Software erstellen. Natürlich kann man einige Warnungen/Hinweise ignorieren, wenn man weiss, was man tut.

@mkinzler: Das, was in Delphi eine Warnung ist ("Funktion liefert u.U. kein Resultat", "Variable ist nicht initialisiert") ist in C# beispielsweise ein Fehler. Und das ist es ja auch! Zwar kein syntaktischer Fehler, aber dafür ein sematischer. Oder kennt einer von Euch ein Einsatzgebiet, in dem so ein Konstrukt Sinn ergibt?

Ich habe bei mir alle Warnungen eingeschaltet, ausgenommen die Warnungen für 'Unsicheren Code/Typ/Typumwandlung'. Ich habe es mir zur Angewohnheit gemacht, alle Warnungen und Hinweise in Ordnung zu bringen und empfinde Fremdmodule, die mir die Warnungen nur so um die Ohren hauen, als Laiengeschmier. Meistens (oder eigentlich immer) sind sie es nach genauerem Hinsehen dann auch.

[Dezipaitor]

Boah, ich glaube meine Fragen wurden völlig falsch interpretiert.

Ich habe nichts gegen das Warnungssystem! Bei JWSCL habe ich sogar alle "echten" Warnungen korrigiert, so dass nur noch "Text hinter dem end. wird vom Compiler ignoriert" existiert. Der Text, der da genannt wird ist übrigens ein {$ENDIF}.

Warum Warnungen ausschalten im Quelltext? Für manche Warnungen oder Hinweise (deprecated, plattformabhängig usw), wäre das wirklich fabelhaft, weil sie eigentlich nur stören und keinen Sinn für die Situation haben.

Worauf ich mich beziehe ist das hier :
http://members.aye.net/~bstowers/del...ndWarnings.htm (bitte zu Bug #148; scrollen)

Zitat:

There are bugs in Delphi 2.0 and Delphi 3.0 that relate to the "localness" of the $HINTS and $WARNINGS directives. These directives do not have the same scope as other local directives like the $ALIGN directive.

PS.
Sollten Warnungen irgendwann fest als Fehler erkannt werden, dann kann ich schon jetzt vorhersagen, dass es einige Delphientwickler weniger geben wird (und ich bin keiner davon). Aber selbst C++ ist da 100% flexibler. Und so hätte ichs auch gerne für die Warnungen.

[calculon]

Zitat von Phoenix:

[..] Ich liefere z.B. auch keinen Code aus, der auch nur einen Hinweis enthält. [..]

Auch nicht mit diesem ?

Zitat:

[Warnung] uMain.pas(7): Unit 'FileCtrl' ist plattformspezifisch

Gruß
--

[Phoenix]

Nein. Aber meine Anwendungen enthalten auch die Unit FileCtrl nicht

[calculon]

Na dann, RESCHPEKT! Ich benutze sie des öfteren und die Warnung hatte mich anfangs irritiert. Inzwischen ignoriere ich sie einfach

Gruß
--

[alzaimar]

Zitat von Dezipaitor:

Warum Warnungen ausschalten im Quelltext? Für manche Warnungen oder Hinweise (deprecated,...

Nun ja. Mein Code soll ein paar Jahre halten und da ist es schon sinnvoll, auf soetwas aufmerksam gemacht zu werden. Daher kann man sie ja individuell ein/ausschalten.

Zitat von Dezipaitor:

Worauf ich mich beziehe ist das hier

Was für ein dämlich konstruierter 'Bug'. Wer soetwas kodiert, gehört geteert und gefedert. Soll er doch gleich C oder ASM nehmen. Buäh.

Zitat von Dezipaitor:

Sollten Warnungen irgendwann fest als Fehler erkannt werden, dann kann ich schon jetzt vorhersagen, dass es einige Delphientwickler weniger geben wird

Die (Entwickler)-Welt wird sich nach deiner Auffassung in zwei Lager spalten:
1. Die "Wir-entwickeln-sicheren-Code"-Fraktion.
Bevorzugte Sprachen: z.B. C#, Java oder auch Delphi (wenn Delphi so lange überlebt)

2. Die "Was-soll-der-Mist-ich-bin-der-Herr-über-meinen-Code"-Fraktion
Ent(fr/w)ickelt wird in C, C++ und anderen Verdächtigen und die sind dann weiterhin für die vielen Bufferoverflows und schlechten Programme verantwortlich.

Natürlich muss man die Warnungen und Hinweise genau studieren. Ich für meinen Teil begrüße die Möglichkeit, sich Warnungen als Fehler anzeigen lassen zu können.

Zitat von calculon:

Na dann, RESCHPEKT! Ich benutze sie des öfteren und die Warnung hatte mich anfangs irritiert. Inzwischen ignoriere ich sie einfach

[ ] Du entwickelst robusten Code.

[divBy0]

Zitat:

[Warnung] uMain.pas(7): Unit 'FileCtrl' ist plattformspezifisch

Das ist bei mir eigentlich immer die einzigste Warnung, die bestehen bleibt. Kann man denn eine Unit/Programm als reine Win32-Plattform kennzeichnen oder wie "umgeht" ihr die Warnung?

Alternativen?

[calculon]

Zitat von divBy0:

Zitat:

[Warnung] uMain.pas(7): Unit 'FileCtrl' ist plattformspezifisch

Das ist bei mir eigentlich immer die einzigste Warnung, die bestehen bleibt. Kann man denn eine Unit/Programm als reine Win32-Plattform kennzeichnen oder wie "umgeht" ihr die Warnung?

Alternativen?

Zitat von Delphi Hilfe:

Die gesamte Unit ist (mit der Hinweisdirektive platform) als eine gekennzeichnet, die Inhalte enthält, die nicht auf allen Plattformen verfügbar sind. Wenn Sie plattformübergreifende Anwendungen erstellen, kann dies zu Problemen führen. Beispielsweise wird platform bei Units mit Objekten angegeben, die in OleAuto definiert sind.

Mit der Compiler-Direktive $WARN UNIT_PLATFORM ON/OFF können alle derartigen Warnungen für Units aktiviert oder deaktiviert werden.

Zitat von alzaimar:

Zitat von calculon:

Na dann, RESCHPEKT! Ich benutze sie des öfteren und die Warnung hatte mich anfangs irritiert. Inzwischen ignoriere ich sie einfach

[ ] Du entwickelst robusten Code.

[X] People like me just don't give a shit

Gruß
--

[alzaimar]

Zitat von calculon:

Zitat von alzaimar:

[ ] Du entwickelst robusten Code.

[X] People like me just don't give a shit

[X] So then halts doch your Mowl when Earwaxene sish underholden.

Nee, nee. Is schon ok. Jedem das Seine...