Hallo Zusammen,

seit kruzem zeigt mir das Ausgabefenster des Debuggers ungefähr 100mal folgende Zeile:
Eine Ausnahme (erste Chance) des Typs "MySql.Data.MySqlClient.MySqlException" ist in MySql.Data.dll aufgetreten.

Das Debuggen dauert seit dem auch extrem lange aber schlussendlich läuft das Programm....
Hat soetwas jemand schonmal gesehen?
LG Christof

Das einzige was mir dazu einfällt: TryCatch ist ein heißes Eisen
Also entferne alle TryCatches, die keine wirkliche Fehlerbehandlung ausführen, sodass der Debugger wieder seinen Dienst tun kann.

Hi,
vielen Dank üfr den Tipp!
Hab darüber noch gar nicht nachgedacht und es klingt total plausibel.

Ist ne sehr interessante Theorie und je mehr ich drüber nachdenke umso mehr stimme ich deiner konstruktiven anti-TryCatch-Theorie zu!
Ich probiere mal in ner ruhigen Minute mal die TryCatches zu entfernen und werde hier von meinen Erfahrungen berichten.
Schönes Wochenende noch!

Nur als Anmerkung. Alle Try-Catch Blöcke entfernen ist auch der falsche Ansatz. Nur sollte man diese bewusst setzen. Und nicht einfach überall reinklatschen.

Zumindest beim Debugging sollten diese da raus, wo man grade anfängt, sodass man Exceptions bekommt, die je nachdem auftreten können, um zu sehen, was man absichern muss. Und erst dann nach richtiger Behandlung und guter Überlegung diese richtig abfangen.

christof86 schrieb:

anti-TryCatch-Theorie

thefiloe schrieb:

Alle Try-Catch Blöcke entfernen ist auch der falsche Ansatz.

"Meine" Theorie ist garnicht wirklich "Anti-TryCatch". Ich nehme nur das Konzept Fehlerbehandlung so ernst, wies gemeint ist:
"Behandle nur die Fehler, die du auch behandeln kannst."
Die anderen nicht.
Da die TryCatcherei aber eine dieser Seuchen ist, mit denen jeder Hurgler sich sofort ansteckt, die Krankheit aber von selbst bei keinem abheilt - nur deswegen erscheinen meine Einlassungen so als Anti-TryCatch.

Dass du das nicht so meinst, ist mir schon bewusst. Nur wird das oft falsch interpretiert.

Jo, es läuft inne Praxis ja auch tatsächlich drauf hinaus, während der Entwicklung 95% - 100% aller TryCatchens zu entfernen.
Denn solange ein Proggi noch nicht ausgeliefert ist, ist eine Fehlermeldung ja keine Fehlfunktion, sondern eine überaus kostbare Programmier-Hilfe.
Meist können Behandlungen, die übers Fehler-Ignorieren hinausgehen, sowieso erst ab Feature-Completeness sinnvoll konzipiert werden.

Ich muss sagen, ich mach direkt da Try/Catch rum, wo ich weiß, was für Exceptions auftreten und wo ich sie nicht wirklich verhindern kann. Ansonsten frag ich da halt ggf was ab o. ä. Und wenn mal was verschluckt wird, dann mach ich's wieder weg oder lass mir die Exeption im Catch ausgeben. Das ist dämlich ich weiß, aber am Ende vergesse ich sonst eventuell, die Blöcke hinzumachen oder ich möchte den bestimmten Teil dann einfach gleich fertig machen.

Gegen das Vergessen gibts das ToDo-Listen-Feature vom VS. Weil wenn du deinen halbgaren TryCatch vergisst...

Aber ist alles im Tut angesprochen und erläutert.

Hi,
"anti-Try-CatchTheorie" war von mir warscheinlich deutlich härter ausgedrückt als ich es beabsichtigt habe. Habe verstanden, was Du uns mit dem Post vermitteln möchtest, bin aber leider was das Thema angeht noch viel zu grün hinter den Ohren, als das ich konstruktiv hier mitreden könnte...

Aber eins interssiert mich dennoch:
Warum hat das ein so großen Einfluss auf die Zeit die mein Rechner fürs debuggen benötigt? Das Debuggen hat meiner Logik nach noch nichts mit den TryCatch'es am Hut, oder doch?

VG Chris

Exceptions sind relativ lahm in der Ausführung, auch wenn man die wegfängt (Try-Catch). Also sollte man mit Exceptions sparsam bis gar nicht umgehen. Ab und an braucht man sie allerdings, zum Beispiel, wenn ein Benutzer eine Datei öffnen möchte, auf die er keine Rechte hat. In dem Fall sollte man diese Exception fangen und dem Benutzer dies mitteilen.

christof86 schrieb:

Warum hat das ein so großen Einfluss auf die Zeit die mein Rechner fürs debuggen benötigt?

Ist nur eine Vermutung.
Bei unsachgemäßen TryCatches kann ja beliebiger Mist ablaufen, u.U. ohne dass du was davon mitkriegst.
Und ist halt denkbar, dass auch ein stark performance-fressender Mist dabei ist.

Aber normal werden auch verschluckte Exceptions wenigstens ins Ausgabefenster geloggt - hast du Einsicht ins Ausgabefenster?
Falls nicht, auch dieses Loggen ist unperformant, also eine Schleife mit 300 Durchläufen, und in jedem wäre eine Exception zu loggen - das laggt.

ok,
in meinem Fall ist es so, dass ich jedesmal wenn eine Verbindung zur MySQL Datenbank ein TryCatch verwendet habe.... weil mir das nette Tutorial was ich mir mal angesehen habe es so erklärt hat.
Ist es eurer Meinung nach sinnvoll es dabei zu verwenden?
Beispiel:

Guck einfach, was deine "Behandlung" macht:
Sie zeigt die Fehlermeldung an, und schließt dann die Anwendung.
Ok, das ist gut und sicher, v.a. so können keine Daten korrumpieren.

Aber wenn du den TryCatch weglässt - was passiert dann?
Jawoll: VisualStudio zeigt die Fehlermeldung an, und schließt dann die Anwendung.
Merksch was?
Nur dass die Fehler-Anzeige durch das VS um Welten besser ist als deine elende Messagebox

Ähm - ... - Aber das ist doch langsam öde, weil das ist doch genau das Beispiel, mit dem ich mein TryCatch-Pamphlet überhaupt eröffne? Wieso muss ich das jedes jedes Mal bei jedem einzelnen immer wieder von neuem durchgehen?
Kann nicht mal irgendeiner daherkommen, das Tut lesen und einfach verstehen wies da steht - muss ich das immer wieder jedem nochmal vorlesen?
Weil das vorgelesene kann ich ja auch nur in diesen Post schreiben, und dann mustes doch nochmal lesen - wofür schreib ich eiglich Tuts?

So oder so. Haut die verdammten MessageBoxen raus. Man kann mit MessageBoxen NICHT debuggen. Schluss fertig aus. Es geht einfach nicht.
Außerdem nur als Tipp am Rande: Es gibt das Entity Framework auch für MySQL: codeproject.com/Tips/426790/Us…SQL-with-Entity-Framework