Was mich ganz irre macht beim Arbeiten mit Microsofts .net-Kram in der Firma ist nicht etwa hauptsächlich die Abneigung gegen die Firma, die das produziert, sondern diese kleinen Produktivitätshemmnisse, gegen die ich immer wieder renne.
Beispiel von heute: ich bekomme eine NullReferenceException von ganz tief unten im Microsoft-Code, wenn ich aus einer Gruppe von Radio-Buttons (diese runden Checkbox-ähnlichen Dinger, von denen immer nur eine ausgewählt sein kann) eine als angewählt markiere. Da staunt man: wie kann es sein, dass diese Exception, die klar einen Programmierfehler signalisiert und sonst gar nichts — und die überhaupt nicht hilfreich ist, weil sie mir nicht sagt, was ich falsch gemacht haben könnte — mitten aus der Library heraus geworfen wird?Sowas darf eigentlich nicht passieren.
Tut es eigentlich aber auch nicht wirklich — der Fehler kam nämlich aus meinem Code. Und wurde ganz woanders geworfen, nämlich an einer Stelle, die über drei Ecken dadurch getriggert wurde, dass vor dem Markieren des einen Radio-Buttons ja erstmal der andere, der gerade ausgewählt ist, abgewählt werden muss. Und irgendwo ganz weit unten im Code von Microsoft steht dann vermutlich in etwa sowas hier:
try {
...
} catch (Exception e) {
...
throw e;
}
… und schon sieht das für mich aus, als käme die Exception von da, weil alle Informationen über die Stelle, von wo sie eigentlich kommen, in dem Moment überschrieben werden, wo die Exception wieder geworfen wird.
Das ist ein Bug. Und der hat mich heute eine Viertelstunde gekostet.
Wenn ich jetzt sage, dass mir sowas in meiner ganzen Laufbahn als Java-Programmierer mit den Libraries von Sun noch nie passiert ist, dann hat das sicherlich was mit Glück zu tun — aber ganz bestimmt nicht ausschließlich.
Library-Bugs dieser Art kosten mich eine ganze Menge Nerven, meinen Arbeitgeber bares Geld, und Microsoft hoffentlich aus genau diesen Gründen auf die Dauer Kunden.
