Exceptions treiben mich noch irgendwann mal zum Wahnsinn. Damit ich herausfinde wo es kracht, muß ich im Debugger "Break on Exception" aktivieren. Dann bleibt er stehen wenn eine auftritt, auch wenn sie behandelt wird. Jetzt ist aber der Code gerammelt voll mit Aktivitäten wie:

try {
// lade irgend ein bitmap
..
}
catch( .. ) { .. }

Auf den Entwicklungsmaschinen und beim Kunden gibt es oft diese Bitmaps nicht. Macht aber auch nichts, ist ja nur eye candy. Jetzt kann ich entweder o.g. Einstellung wieder deaktivieren oder endlos "continue" klicken, bis der Ausführung irgendwann einmal an einer interessanten Stelle angekommen ist.
Ok, das kann man jetzt als eine lästige Nerverei abtun. Aber hier steckt noch ein viel fundamentaleres Problem dahinter. Das Abfangen der Exception bewirkt nämlich, daß der möglicherweise komplett verbuggte Code *hinter* der die Exception auslösenden Stelle nie ausgeführt wird. Passiert das eines Tages doch (z.B. beim Kunden), wundert man sich über heitere Nebeneffekte. Dahinter steckt die Denkweise, Exceptions wie gotos zu verwenden. Ich finde das grauenhaft.
Warum nicht so

if(File.Exists(filename)) {
// lade bitmap ....
}

Daher sollte man o.g. Code einfach schnell vergessen. Die Regel muß einfach lauten "wirf nur dann, wenn es wirklich was zu werfen gibt!" (und dann sollte es auch OK sein, wenn das Programm mit einem schönen Exceptiondialog abrauscht).