Try Catch Probleme mit "nothing" ?

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Try Catch Probleme mit "nothing" ?

    Hi,

    Mein Try Catch fängt einen "Null-Reference" nicht ab, siehe Anhang...
    Klar, ich mache jetzt einen Test "If nothing...", das geht, aber warum klappt der Try Catch nicht?

    Das ging früher mal... Ich habe das Programm überarbeitet und mit dem neuen Framework versehen,
    kann das sein das sich da was geändert hat?!?

    Bye,

    Dilbert
    Bilder

    • fehler.png

      42,08 kB, 882×416, 106 mal angesehen

    Weil Du beim Debuggen bist. Im fertigen Programm kommt die sinnfreie MessageBox. Setzt Du allerdings bei der CheckBox unten rechts im Bild ein Haken, dass in Deinem Code bei dieser Ausnahme nicht unterbrochen werden soll, dürfte auch die MessageBox bei Dir kommen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @Dilbert Wozu brauchst Du ein Try / Catch, wenn Du elementar abfragen kannst, was da los ist:

    VB.NET-Quellcode

    1. If InternControl IsNot Nothing Then
    2. InternControl.Enabled = Erg
    3. End If
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ja, hatte ich ja schon geschrieben das das funzt.
    Der Code ist auch nur ein abgespecktes Beispiel, nicht ernst nehmen, schlechter Stil!

    Worum es mir geht ist:
    WARUM?
    Warum wird das nicht von einem Try Catch gefangen?

    Bye,

    Dilbert
    P.S.: Stimmt, im fertigen Programm klappt das. Ist mir noch nicht aufgefallen! Obwohl ich die Debug-Version starte.
    Geht also nur bei Debugger attached...
    Muss also mit Visual Studio zusammenhängen. Ich nehm' das mal so hin.

    Dilbert schrieb:

    WARUM?
    Warum wird das nicht von einem Try Catch gefangen?

    Darum:

    VaporiZed schrieb:

    Weil Du beim Debuggen bist. Im fertigen Programm kommt die sinnfreie MessageBox. Setzt Du allerdings bei der CheckBox unten rechts im Bild ein Haken, dass in Deinem Code bei dieser Ausnahme nicht unterbrochen werden soll, dürfte auch die MessageBox bei Dir kommen.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    OK, die Antworten haben sich etwas überlappt, daher zusammengefasst:

    Ja, der Code macht etwas mehr als nur msgbox(ex.message) auszuzgeben.
    Unnötigen Ballast habe ich entfernt, damit das Problem klarer wird.
    Daher ist der Stil etwas ... seltsam ;)

    @VaporiZed:
    Ja, das hat schon mal geholfen und mich auf die richtige Spur gebracht. Danke.

    Bleibt:
    Warum wirft die Entwicklungsumgebung Exceptions, die im fertigen Programm abgefangen werden?
    Hat das irgendeinen Vorteil?

    Bye,

    Dilbert

    Naja, die Debugging-Session ist zum Debuggen da. Lies den von mir verlinkten Thread durch. Es geht darum, den Fehler präventiv zu beheben. Dabei will Dir der Debugger helfen. Und dazu machen sich Exceptions in vollem Ausmaß mit dem vollen Infobild einfach gut.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @VaporiZed:
    Welchen verlinkten Thread?
    Ja, mag sein dass der Debugger zum Debuggen ist, wer hätte das gedacht, aber den Fehler habe ich ja nun abgefangen. Mit Absicht.
    Und das macht er (bisher) nur bei "Nothing" Exceptions.
    Es wäre ja wirklich auch grausam, wenn er plötzlich bei jedem bereits abgefangenen Fehler stoppen würde!
    Dafür mache ich ja ein Try Catch drum.
    Ich schnall's nicht.

    Ach, und @SpaceyX:
    Das klappt leider nicht bei der Zuordnung von Propertys ...

    Bye,

    Dilbert

    Siehe Post#2 das blau markierte sinnfreie MessageBox. Das ist n Link.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Hey, du kannst in Visual Studio einstellen, bei welchen Exceptions dieses Verhalten auftritt (es ist nicht *nur* bei NullReferenceExceptions so). Siehe dazu das Bild im Anhang. Wenn du im Fenster die NRE abschaltest, wird der Debugger nicht mehr pausieren, solange du ein try/catch nutzt.

    Allerdings ist dieses Verhalten bei einigen Exceptions sinnvoll, besonders bei der NullReferenceException, da diese immer zu 100% ein Fehler des Programmierers ist, der eben nicht per try/catch gefangen werden sollte. Kurz gesagt: Du sollst schmerzlich merken, wenn diese Art von Exception auftritt, damit du sie beheben kannst. Dieses Behavior wird schnell nützlich, wenn du in einem try/catch *jede* Exception abfängst. Siehe dazu folgenden Code:

    C#-Quellcode

    1. static void Main(string[] args)
    2. {
    3. try
    4. {
    5. var fictionalUploadClient = CreateClient();
    6. var fileContent = File.ReadAllText("fileToUpload.txt");
    7. await fictionalUploadClient.UploadAsync(fileContent);
    8. }
    9. catch
    10. {
    11. Console.WriteLine("Uploading failed.");
    12. }
    14. // Irgendwo in einer anderen Datei:
    15. static FictionalUploadClient CreateClient()
    16. {
    17. return null; // TODO.
    18. }
    19. }


    Hier wirst du als Entwickler immer die Fehlermeldung "Uploading failed." bekommen. Damit könnte man beim Debuggen schnell denken, dass etwas beim Einlesen der Datei oder beim Hochladen mit dem Netzwerk nicht stimmt. Aber falsch: Der fictionalUploadClient ist leider null, weswegen du eine NullReferenceException bekommst. Das try/catch fängt das leider ab und du debuggst eventuell lange Zeit an der falschen Stelle. Wenn Visual Studio trotz dem try/catch bricht, bemerkst du den Fehler hingegen sehr sehr schnell und kannst ihn ganz leicht beheben.

    (Disclaimer: Das Beispiel ist natürlich sehr vereinfacht - aber Code dieser Art, also generelle try/catch'es, wirst du in vielen Projekten finden.)
    Bilder

    • steps.png

      52,6 kB, 788×882, 76 mal angesehen

    @VaporiZed:
    Ach sooo, den meinst du. Ja, das ist mir schon klar, sowas mache ich normalerweise nicht. Da stimme ich voll mit dem Link überein.
    (Und ich werde nie wieder "vereinfachten" Code posten, nächstes mal schicke ich alle 10.000 Zeilen :P )

    @shad:
    OK, wenn der Programmierer tatsächlich so'n Bockmist baut, ... dann mag es Hilfreich sein TROTZDEM 'ne Exception knallen zu lassen...
    Obwohl ich ja immer der Meinung bin: "Lernen durch Schmerz"
    Das hilft am Besten :D

    Und in deinem Beispiel greift der Link von VaporiZed :)

    OK, ob so 'ne "Bevormundung" schlau ist lasse ich wieder offen, weil ich zu Debug-Zwecken oft schnell mal 'n TryCatch drum baue, dann nervt es, wenn er das doch wieder meldet.
    (Natürlich wird das im Final wieder überarbeitet, aber zum Debuggen find ich das recht nützlich.)

    Aber das Bild im Anhang hat mir zu meinem Glück gefehlt!
    Man kann ihm das also abgewöhnen! DANKE!!! :thumbsup:

    Bye,

    Dilbert

    Dilbert schrieb:

    Worum es mir geht ist:
    WARUM?
    Warum wird das nicht von einem Try Catch gefangen?
    Der Debugger ist noch schlauer: Er zeigt dir den Fehler, und dann kannst du wenn wolle mit F5 oder F8 das Programm einfach weiter laufen lassen - und der Catch wird den Fehler dann auch fangen.
    Also es stimmt gar nicht, dass der Fehler nicht gefangen würde.


    Dilbert schrieb:

    weil ich zu Debug-Zwecken oft schnell mal 'n TryCatch drum baue, dann nervt es, wenn er das doch wieder meldet.
    (Natürlich wird das im Final wieder überarbeitet, aber zum Debuggen find ich das recht nützlich.)
    es ist Unfug, zu Debug-Zwecken einen TryCatch zu bauen.
    Lass den Debugger seinen Job machen - nämlich dir die Fehler zeigen.
    Das macht er besser als jeder "zu Debug-Zwecken hingemachte TryCatch", den du später doch wieder überarbeiten musst (wenn du im Final da noch dran denkst).

    siehe auch TryCatch ist ein heißes Eisen

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Dilbert schrieb:

    nicht ernst nehmen
    Ich bitte darum, dass beim nächsten Mal ernstzunehmender Code gepostet wird.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!