hans im glück schrieb:

Anscliessend habe ich den gesamten Code im Form Load Event auskommentiert

Kommentier ihn nicht aus, sondern packe ihn ins Form_Shown-Event,
Im Load-Event werden häufig die Events unterdrückt.

hans im glück schrieb:

eine plausible erklärung

gibt es dafür nicht, jedoch beliebig viele Beiträge auch hier im Forum.
Im Framework ist da wohl ein spezielles Try / Catch um den Form_Load-Aufruf gepackt, der nur spezielle Exceptions knallen lässt.

@hans im glück Das ist doch das, was erwartet wird.
Wenn innerhalb eines Codes eine Exception auftritt, wird diese vom nächst inneren Try/Catch-Block abgefangen, es sei denn, der fängt diese spezielle Exception nicht ab.
Wenn Du 2 Try/Catch-Blöcke schachtelst, wird zuerst der innere, danach, wenn überhaupt, der äußere angesprungen.

@hans im glück Ist korrekt.
Da hilft tatsächlich nur, das Form_Load-Event zu meiden und auf Form_Shown oder Button_Click (und solch) auszuweichen.

Gleiches Problem mit dem Debugger habe ich allerdings nicht nur bei "Form_Load" sondern auch z.B. wenn ich mit Tasks arbeite (Tcp) - wenn ich Try-Catch setze dann wird die Exception abgefangen und ich kann diese mir anzeigen lassen, andernfalls ohne Try-Catch wird der Task einfach beendet, selbst wenn ich im Debugger mit Einzelschritt durchgehe.

@Thias Debuggen in einem Thread ist nicht Debuggen im Mainthread.

@RodFromGermany Na und? - wenn man mit Begeisterung und jugendlichen Leichtsinn mit dem Programmieren beginnt, dann wird man sich erst einmal über diesen Unterschied keine große Gedanken machen und sich auf einmal genauso wundern wie bei "Form_Load" - insbesondere da ja, wenn keine Exception fliegt, wunderbar mit dem Debugger per Haltepunkt und Einzelschritt auch im Task durchgegangen werden kann.

Von daher sollte da schon darauf hingewiesen werden!

hans im glück schrieb:

schon, jedoch ist das ein beispiel das für nicht profis - wie ich es einer bin - diese predigt (bitte nicht falsch verstehen, macht ja sinn) in gewisser weise wiederlegt.
natürlich nur im kontext mit dem auftreten im load event

Jo, dieser lausige Windows-Bug ist nicht vernünftig in Einklang zu bringen mit meiner TryCatch-Predigt:
Entweder man verlegt seinen Code raus aus dem Startup, um wieder in den Genuss der Standard-Fehlerbehandlung der IDE zu kommen (was ich ja predige, dass das die beste Fehlerbehandlung von allen ist, wenn man die Fehler beheben will)
Oder man muss einen eigenen TryCatch hin-machen, wo eiglich keinesfalls einer hingehören täte.
(Aber in dem Fall gehört er halt hin, nämlich weil MS es nicht gebacken kriegt im Startup - wohlgemerkt: nur im Startup, ansonsten ja durchaus.)

Das eine wie das andere sehr unschön.
(Also Verlegen ist prinzipiell nicht unschön, nur meist hat man gute Gründe, wenn man Code im Startup anlegt, und fängt sich Nachteile (meist etwas verzögerter Startup) ein, wenn man ihn umverlagert.

Noch eine Bemerkung zur TryCatch-"Predigt": Die ist falsch verstanden, wenn man sie so versteht, dass man kein TryCatch verwenden soll.
Ich empfehle zwar rigoros, TryCatch zu vermeiden, wann immer es geht.
Aber damit empfehle ich natürlich ebenso rigoros, TryCatch eben zu verwenden, wenn mans nicht vermeiden kann - das ist eine logische Folgerung, und im Grunde dieselbe Aussage.

jedoch ist das ein beispiel das für nicht profis - wie ich es einer bin - diese predigt (bitte nicht falsch verstehen, macht ja sinn) in gewisser weise wiederlegt.

Kann man auch anders sehen:
Microsoft hat um das Auslösen des Load-Events ein Try-Catch herum gepackt. Man sieht ja, was dabei herausgekommen ist. Wäre das Try-Catch nicht da, dann würde alles ganz normal funktionieren und die Exception würde nicht verschluckt werden.
(Vielleicht gibt es gute Gründe, warum man das so gemacht hat. Ich will hier nicht bestreiten, dass sich jemand bei Microsoft Gedanken drüber gemacht hat.)