Diskussionsthema: Clean Code

Re: Diskussionsthema: Clean Code

Hallo coco,

es gibt genug Situationen, in denen einfach keine Ausnahmen auftreten können. Z.B. wenn du einen FuBa hast mit 4 Eingangswerten und es soll der höchste davon zurückgegeben werden. Was willst du denn da als Ausnahme festlegen? ( Du könntest natürlich extra einen Fehler eingeben, wenn jemand die Zahlen 153, 370, 371 und 407 eingibt damit du eine Ausnahmebehandlung einfügen kannst. )

Re: Diskussionsthema: Clean Code

c oco hat geschrieben:- Definition von Ausnahmeparametern sollten in Funktionsbausteinen immer zwingend sein oder kann es auch sein, dass es in der gerufenen
Einheit gar keine Fehlerkonstellation auftreten kann?

Nochmal hierzu. Ein Ausnahmeparameter macht nur dann Sinn, wenn du im FuBa auch ein RAISE machst. Und das kannst du ja nur dann machen, wenn eine dir bekannte Ausnahmesituation vorliegt oder wenn du daran denkst, dass etwas bestimmtes schief gehen könnte. Wenn dir da aber nix einfällt kannst du auch kein RAISE machen --> keine Ausnahme.
Falls du aber wie von adt schon erwähnt an RFC-Bausteine denkst - ich kann mich nicht erinnern jemals einen RFC-Fuba verwendet zu haben ohne die beiden RFC-Ausnahmen abgefangen und zu bearbeitet zu haben.

c oco hat geschrieben: bei Klassenbasierten Ausnahmen bin ich der Meinung, dass es keine leeren Ausnahmebehandlungen geben sollte. Oder kann es auch Fälle geben, in denen es gewollt ist, nicht auf einen Fehler zu reagieren und die weitere Verarbeitung fortzuführen?

Das hängt ganz stark davon ab, was die Ausnahme sagen soll. Ich habe z.B. eine Migration, wo wir diverse Umsetzungen machen - und leider kann die Umsetzung von Zeit zu Zeit auch einen korrekten initialen Wert zurückgeben. Was wir wissen müssen ist nur, ob die Umsetzung geklappt hat oder nicht, da im letzteren Fall alternative, komplexere oder zeitintensivere Methoden zur Umsetzung herangezogen werden müssen. Und eine nicht gefundene Umstzung wird dann in meinen Umsetzungklassen mittels RAISE EXCEPTION angekündigt. Insgesamt sieht dann die Kaskade der Umsetzungen etwa so aus. Ist jetzt zwar etwas geschummelt, da man das "RETURN" auch weglassen könnte und dann den 2. TRY-CATCH-Block in das CATCH des 1. Block schieben könnte. Aber wenn die Anzahl der Umsetzversuche sich erhöhrt wird das Coding unübersichtlicher und so sieht man dann schön spätestens im Debugger wie weit man gehen musst um endlich die Umsetzung zu finden.
Und ehrlich gesagt fallen mir noch 1000 andere Umstände ein, unter denen ein leerer Catch-Block durchaus seine Berechtigung hat.