SOGHotlineExceptions ("Interner Fehler. Bitte an SOG Hotline/Entwicklung weitergeben!") werden immer dann ausgegeben, wenn eine Exception ohne jegliche Aussagekraft entsteht und bis zum Anwender vordringt. Dies sind oftmals Exceptions wie System.ArgumentException, System.NullReferenceException usw.
Diese Art der Fehlermeldungen müssen IMMER durch einen Entwickler bearbeitet werden, eine sinnvolle Analyse/ Behebung durch die Hotline/ Projektleitung bzw. den Anwender ist nicht möglich.
Eine aktive Voranalyse/ Reproduktion (z.B. Anwender, Hotline, ...) ist nicht erforderlich, da die Fehlerursache durch einen Entwickler zuerst beurteilt werden muss.
Für die Beurteilung durch die Entwicklung sind die alle verfügabren Informationen (Wer? Wann? Wie? Was?) hilfreich und sollten an die Entwicklung weitergegeben werden. Sofern nur die Fehlermeldung (z.B. aus SLOG) bzw. wenige Information bekannt sind, ist dies eine Information (z.B. Meldung in SLOG gefunden, tritt mehrach auf) die auch kommuniziert werden muss. Nur die Interne Fehlermledung mit der Information "Interne Fehlermeldung" sind nicht ausreichend/ hilfreich.
Entsprechende Aufgaben müssen immer den Callstack (Fehlermeldungsdatei) enthalten. Ein Entwickler muss immer tätig werden oder in der Aufgabe den Grund festhalten, warum er hier nichts tun kann.
Unabhängig von der eingesetzten Version ist zu prüfen ob das Problem in einem aktuellen Freigabestand bereits behoben ist. Die Prüfung sollte bei älteren Versionen verhältnismäßig sein.
Ein Hotfix in den Stand des Kunden ist nur gemäß der internen Vorgaben erlaubt. Eine Korrektur im Entwicklungsstand bzw. der aktuellen Freigabe sollte immer erfolgen.
Es reicht nicht, nur etwaige Datenzustände zu korrigieren oder zu vermeiden, da sonst das Potential für den gleichen Fehler nach wie vor im Quellcode vorhanden ist!
Neben der (Daten-)Situation, die zu diesem Fehler führen konnte, muss auch die eigentliche Exception in Zukunft vermieden werden. Anstelle der SOGHotlineException muss entweder eine sprechende Fehlermeldung geworfen oder die Quellcodepassage um eine technisch vernünftige Prüfungen ergänzt werden.
Korrekturen sollten immer in HDL und der aktuellen Freigabe erfolgen, in älteren Freigaben nur in Rücksprache mit EW-Leitung bzw. der QS.
Reine technische Anpassung der technischen Fehlermeldung (Phase 1), welche per Hotfix ausgeliefert werden sollte (wenn aktueller Stand eingesetzt wird)
Klare Kommunikation das Fehler NICHT korrigiert wurde, sondern nur eine sprechende Fehlermeldung ausgegeben wird
Gerade bei allgemeinen bzw. globalen Funktionen ist es wichtig, dass die Korrektur möglichst dort passiert, wo die ursprüngliche Exception entstanden ist. Darüber hinaus sollte dann das Auftreten des jetzt sprechenden und verständlichen Fehlers zum Beispiel im auslösenden Programm verhindert werden.
Anpassung der Programmlogik (ggf. aufrufende Methoden) um Fehlermeldung zu verhindern
Die Rückmeldung an den Aufgabenersteller sollte immer eine Information enthalten, ob die technische Fehlermeldung verbessert wurde oder der Fehler/ die Fehlerursache ermittelt und korrigiert werden konnte.
Die SOGHotlineException wurde geschaffen, um den unnötigen Aufwand für Analysen und Qualifizierungen durch die Hotline/ Projektleitung zu reduzieren. In den meisten Fällen ist der Fehler offensichtlich und muss als erstes auf Quellcodeebene behoben werden. Es ist eine für den Anwender/ die Hotline verständlicherer Fehlermeldung zu realisieren, die dann gezielt analysiert und behoben werden kann. Dies ist immer realisierbar auch wenn der Entwickler zu der Funktion selbst keine Aussage treffen kann.
Ist zum Beispiel ein Datenzustand Auslöser einer NullReferenceException, dann sollte als erstes dafür gesorgt werden, dass dort eine Exception entsteht, die den fehlenden Datensatz meldet.
Mut zur Fehlermeldung ist hier das Motto! Funktionen mit sprechenden Fehlermeldungen abzusichern erhöht die Möglichkeit der Analyse und Problembehebung durch Nichtentwickler.
Jedoch muss vermieden werden, Fehlermeldungen zu anonymisieren. Ein try-catch der alle möglichen Exceptions abhandelt und anschließend meldet, der Datensatz sei nicht vorhanden, wäre in allen anderen Fehlersituationen irreführend und würde unnötig viel Analyseaufwand produzieren. Ist das Vorgehen zur Anreicherung von Fehlermeldungen nicht offensichtlich, soll ein 2. Entwickler zu Rate gezogen werden.
Durch die Entwicklung bereitgestellten Hotfixe erfolgt i.d.R eine Verbesserung der Meldung (Sprechende Meldung anstelle der technischen Fehlermeldung). In bestimmten Situationen kann aber auch das Problem korrigiert sein. Hier bitte die Rückmeldung der Entwicklung beachten und an den Kunden entsprechend kommunizieren.
Sofern nur die Meldung verbessert wurde, sollte der Anwender darauf hingewiesen werden, dass er sich mit der neuen Meldung an die Hotline wenden möge sofern er Unterstützung bei der Analyse/ Klärung benötigt.