Da waren fünf leere machwas() Prozeduren im Code?
Leider nein... in den Prozeduren bzw. irgendwo anders im Programm und sogar in Threads wurde das "globale rwsflag" eventuell irgendwann irgendwo gesetzt.
Man vertrat dort die Idee, das dies insbesondere bei Fehlern in und mit verschiedenen Quelltexten/Treads welche beim "Init" einmalig den Pointer auf das "globale rwsflag" bekamen, dann im&mit Threads besser ist wie zig Exceptions zu werfen.
OK, wenn man weiß wie es gedacht ist dann loggt man seine Fehler im "Klartext" eben bei Bedarf selbst und wenn was "ganz böses" passiert ist, dann teilt man es allen anderen durch das flag mit. Ob und wie die reagieren, darum kümmert man sich selbst nicht... quasi "kooperatives Errormanagement", so wie gaaanz früher das kooperative MultiTasking mit der Win16-
API
Das "Wissen" umd das, was sich der "Qelltextverursacher" dabei wohl gedacht hat"... und es uns nun durch seine "Kommentare" oder was auch immer sagen wollte... genau darum geht es doch hier
Solange ein fremder Quelltext eine erkennbare in sich einheitliche Struktur hat, bin ich schon sehr glücklich. Denn das weiß ich zumindest das der der es gemacht hat es an der Stelle wo ich gerade suche nicht zufällig mal so gemacht hat wie es dasteht. Da zu sagen, die Quelle und/oder die Struktur ist Schrott bringt halt nicht weiter, wenn der Auftraggeber "jetzt" eine Aussage über den Aufwand einer einzelnen punktuellen Fehlerbeseitigung will. Klar sage ich in solchen Fällen das man es heutzutage doch etwas anders und nach Standards besser machen "sollte", aber im Sinne von "NeverTouchArunningSystem" mach ich mir liebeer die Mühe eine Klainigkeit notfalls auch mit etwas Aufwand im "alten FremdSource" zu ändern, als das ich etwas neu eingebautes in Bezug auf "Funktionskompatibilität" dann komplett selbst verantworten muss.
Ich hatte schon Fälle, da war in 1 aus 256 Fällen eine Checksumme falsch und weil ich "ordentlich" war hatte ich das "nebenbei" mit korregiert. Dumm war nur das es nun in 1 aus 256 Fällen einen "zufälligen" Fehler mit einer Datenkopplung gab, weil deren Interface scheinbar das bisherige 1aus256 Problem (er)kannte und erwartete, deshalb nun nicht mit vollständig korrekten Daten zu recht kam.
=> Ich bin da mittlerweile relativ schmerzfrei und aufwandsorientiert wenn ich mit fremde Quellen ansehe
-> ich habe es in diesem Fall nur ganz leicht erweitert, das "rwsflag" jetzt kein "boolean" mehr ist, sondern ein DWORD als "BitMaske" mit benannten "const" (Bit)Werten ist, wo man an bis zu 32 gesetzten Bits nun zumindest etkennen kann kann "wo überall" Fehler aufgetreten sind
-> "ERWSException" wäre zwar sauber, aber da das war dem Auftraggeber die Sache nicht Wert... die alternative Quick&Dirty Bit-Variante mit bis zu 32 "parallel und einzelen identifizierbaren" Fehlerquellen bekam den Vorzug. Mir war es sogar Recht, denn da musste strukturell quasi nix verändert werden und ich bekam das Projekt schnell wieder abgenommen und vom Tisch