TryCatch im Debug ignorieren

[NSR]

Hi zusammen,

wie die Überschrift schon sagt, suche ich eine Möglichkeit das Fehlerabfangen per Try und Catch im Debuggen zu ignorieren.
Klar könnte man alle trycatchs auskommentieren, aber das dauert mir zu lange.

Gibts da vielleicht eine Einstellung oder spezielle try Catchs die man verwenden kann.

Grad behelf ich mir, indem ich durch Suchen und Ersetzen allen Catchs ein übergabeparameter gegeben habe und dieser ein Fehler ist der nie auftreten kann.

Hoffe Ihr könnt mir helfen,
Nico

 

[deepthroat]

Hi.

Du weißt schon das man das Programm unterbrechen kann sowie eine Ausnahme geworfen wurde (First Chance Exception)?

Debug->Exceptions...

Ansonsten, was sollte denn deine Aktion für einen Sinn haben?

Gruß

 

[NSR]

Hi,

nein wusste ich nicht, bzw. find ich nicht was du meinst. Mir gehts darum, dass ich Leere trycatchs habe einfach damit das Programm sauber läuft auch wenn mal nen Fehler passiert. Aber in den wenigsten fällen mach ich auch was mit den Catchs.
Die Sache ist nun aber die, dass ich um jede methode ein trycatch habe und um die Fehler besser nachvollziehen zu können möchte ich die trycatchs nicht beachten. Sodass das Programm beim Debuggen abstürzt und dann mit dem tollen gelben Hintergrund mir genau sagt was los ist.

ps. ich nutze VS 2010.

 

[Shakie]

[...] dass ich Leere trycatchs habe [...]

Das klingt nach einem ungewöhnlichen Programmierstil. Ich sehe keinen Sinn darin, außer, dass das Debuggen komplizierter wird (wie du selber gerade merkst).
Dennoch kannst du Visual Studio sagen, dass dort angehalten werden soll, wo die Ausnahme geworfen wird, anstatt dort wo sie abgefangen wird.
Wie deepthroat gesagt hat, musst du dazu nach Debug->Exceptions bzw. auf Deutsch Debuggen->Ausnahmen... (Tastenkombination in C#: Strg+D,E) gehen und dann ein Häkchen bei "Thrown" bzw. "Ausgelöst" bei all denjenigen Ausnahmen setzen, bei denen der Debugger sofort anhalten soll. Google ist hier, wie immer, dein Freund: Basic Debugging Features (Zu "Breaking On Exceptions" scrollen)

 

[Spyke]

Leere catches sind immer schlechter Programmierstil.

Ich verwende nur in einem Fall einen leeren catch.
Und zwar wenn ich eine Datei löschen will und da wird auch nur auf IOException geprüft.
(Falls Datei noch in Verwendung ist)

 

[NSR]

Hi,
schlechter Programmierstiel kann ja sein, aber ich darf bei dem Programm nicht riskieren, dass das Programm beim Kunden abstürzt. Und es so lange zu testen, bis ich alle möglichen Fehler herausgefunden habe, dazu fehlt einfach die Zeit.
Aber Danke für die Antworten. Werden es im laufe des Tages mal ausprobieren.
Grüße Nico.

 

[RudolfG]

Hi,

dann empfehle ich dir mal den ExceptionReporter für C#, hier gibt es dann einen Absturz, der Kunde bekommt aber die Möglichkeit dir alle zum Zeitpunkt des Fehlers bekannten Informationen (stack trace) entweder per E-Mail oder Datei zu übermitteln.

Hier hast du dann die genauen Fehlerstellen und durchlaufenen Funktion etc. aufgeführt und kannst die Fehler viel schneller suchen und beseitigen.

Dies sollte dem Kunden tausendmal lieber sein als wenn er auf ein Button klickt und da nichts passiert, weil du die Exception fängst aber darin garnichts machst (und er weiß nicht warum!).

Außerdem kann so der Kunde nach einigen Updates auch überprüfen ob einige Fehler beseitigt wurde und somit ob das Projekt voran geht.

Gruß
RudolfG

 

[CPoly]

Ohne jetzt alle Beiträge genau gelesen zu haben, könntest du es so machen:

try {
    //...
}
catch (Exception ex) {
    //...
    #if DEBUG
    //Wirft die gleiche Exception nochmal
    throw;
    #endif
}