Fehlerhandling - wie weit gehen bei unrealistischen Fehlern?

Ich bin ein großer Fan von gutem Fehlerhandling, v.a. von aussagekräftigen Fehlermeldung, Abfangen erwartbarer Fehleingaben und der Überprüfung von zwingend notwendigen Parametern z.B. per Testfield, damit man nicht irgendwann die Fehlermeldung "Zusteller Code '' nicht gefunden in Tabelle Zusteller", sondern "Standard Zusteller Code darf in Logistik Einrichtung nicht leer sein" kommt.

Ich kenne aber auch Kollegen, die die Tendenz haben, jede Fehleingabe abzufangen, die ihnen einfällt, sei sie realistisch oder nicht. Ich habe da persönlich eine Grenze, bei der ich sage, dass manche Fehleingaben so abwegig sind, dass man der Person, die diese getätigt hat, auf die Finger hauen müsste und sich dann, wenn der Fehler unerwarteterweise doch mal auftreten sollte, darum kümmern muss bevor man den Programmcode dafür so aufbläht, dass die Nachvollziehbarkeit und Wartbarkeit darunter leidet.

V.a., wenn man noch Fallbacks auf Standard-Werte einbaut bei denen es eigentlich keinen Sinn ergibt: entweder der richtige Wert kommt, dann nimmt man den oder es kommt ein falscher, dann kommt eine Fehlermeldung. In dem Moment auf einen Standard-Wert zurückzugreifen, der zwar einen Fehler verhindert, aber dann mit einem auch nicht ganz richtigen Wert weiterarbeitet, ist auch Quatsch. Da wurden jedenfalls schon Lösungen gebaut "wenn x, dann y, außer z, dann a, aber nur wenn b = c, sonst d" anstatt einfach eine Fehlermeldung zuzulassen, am besten dafür sorgen, dass nicht alles abbricht, sondern nur dieser Fehlerfall und dann an geeigneter Stelle der richtigen Person diesen Fehler zu präsentieen.

Wie seht ihr das?

Ich würde solche Fragen am liebsten in einem allgemeinen Programmierung - Dos and Donts - Unterforum stellen, habe dann aber mal einfach dieses hier genommen.

Sofern sinnvoll, überlasse ich die Generierung der Fehlermeldungen der Runtime.

Wenn ein bestimmter Datensatz gefunden werden muss: Record.GET(MyValue); (ohne IF)
Wenn mindestens ein Datensatz gefunden werden muss: Record.FINDFIRST; / Record.FINDLAST; (ohne IF)

Wenn ein Feld gefüllt sein muss: Record.TESTFIELD(MyField);
Wenn ein Feld mit einem bestimmten Wert gefüllt sein muss: Record.TESTFIELD(MyField,MyValue);
Wenn ein Feld leer sein muss: Record.TESTFIELD(MyField,'');
Wenn ein Feld einen bestimmten Wert nicht enthalten darf: Record.FIELDERROR(MyField);

Selbst konstruierte Fehlermeldungen verwende ich nur dann, wenn die systemgenerierte Meldung den Anwender eher verwirrt, anstatt ihn auf die konkrete Ursache hinzuweisen.

Wichtig ist auf jeden Fall, Datumsfelder vor der Verwendung in einer Datumsberechnung (CALCDATE, ...) daraufhin zu prüfen, dass sie gefüllt sind, da ansonsten die Fehlermeldung "Das Datum ist ungültig." erscheint. Das hilft dem Anwender natürlich überhaupt nicht, da weder das Feld, noch die Tabelle, noch der Datensatz genannt wurde.

Alternative Werte werden nur in absoluten Ausnahmefällen verwendet.
Wir unterscheiden z. B. bei unseren Lagerorten nach Lagerorten, auf denen nur Anlagevermögen oder nur Umlaufvermögen liegt.
Darüber hinaus sind unsere Artikel gekennzeichnet, ob es sich dabei immer um Anlagevermögen oder immer um Umlaufvermögen handelt.
Trägt ein Anwender nun einen UV-Artikel in Verbindung mit einem AV-Lagerort in einer Belegzeile ein, dann könnten wir ihm natürlich eine Fehlermeldung um die Ohren hauen. Da auf der Lagerortkarte jedoch der korrespondierende Lagerort hinterlegt ist, kann die Anwendung automatisch den UV-Lagerort ermitteln und in die Belegzeile eintragen.

Unmögliche Datenkonstellationen abzufangen ist meiner Meinung nach Zeitverschwendung in der Programmierung, da die Konstellation ja unmöglich ist.
Extrem unwahrscheinliche (unzulässige) Datenkonstellationen abzufangen ist hingegen sinnvoll, denn solche Fehler fallen in der Regel erst Monate bis Jahre später auf.
Und wenn es sich dann um den Wirtschaftsprüfer handelt, der diese Werte entdeckt, dann steckt man in Erklärungsnöten.

Um die Übersichtlichkeit, Nachvollziehbarkeit und Wartbarkeit bestmöglich zu gewährleisten, haben wir strenge Entwicklungsrichtlinien, dessen Einhaltung auch immer vom Lead Developer geprüft wird.
Diese Richtlinien basieren auf dem damaligen C/AL Guide von Microsoft, welchen wir um viele fehlende Punkte ergänzt haben, unter anderem wie und wo eine Anpassung dokumentiert wird.
So können wir auch Jahre später genau nachvollziehen, wer wann was wo warum geändert hat.