Mein Tipp: Warnungen in den Status einer Exception erheben. Dann werden die auch nicht übersehen.

Je nach Sichtweise gibt es ja durchaus Stimmen, die es besser finden, im Produktiv-Code die warnings zu deaktivieren.

Ich belasse die warnings in aller Regel aktiviert und versuche den Code so zu schreiben, dass warnings regulär kaum auftreten sollten. Wenn sie dann auftreten, schaue ich hinterher, warum sie da waren und versuche, das ebenfalls auszumerzen.

Auf der Basis könnte man rostis Vorschlag aufgreifen und Warnungen fatal machen, sodass sie definitiv auffallen.

Wenn warnings generell abgeschaltet sind, würde ich aber einen Debug-Mechanismus einbauen, womit man sie einschalten kann, oder womit man etwas analoges ausgeben lassen kann. So kann im Fehlerfall die Funktionsweise des Moduls untersucht werden.

Alternativ wäre es vielleicht ein Gedanke, eine Logdatei angegeben zu können, wo die Warnungen reinlaufen können.
So kann man kontrollieren, ob und welche Warnungen aufgetreten sind.

Also ich würde alle Meldungen haben wollen. Bei mir läuft immer alles mit strict und warnings und wird auch immer sofort behoben. Die meisten Sachen fallen bei den Testfällen auf die ich vorab baue.

Wer es nicht haben will kann es doch mit $SIG{__WARN__} separat abfangen und ggf. irgend wo speichern, oder nicht?

Wer auf warnings achtet wird diese auch haben wollen und nicht als Ausnahme abschalten wollen. Und der "ist-nur-'ne-Warnung,-die-kommt-immer" Fraktion kannst du es eh nicht nahe bringen.

Edit: Meine Meinung: warnings nicht abschalten!

Editiert von bianca: Edit ergänzt
Last edited: 2023-03-02 09:37:10 +0100 (CET)