Hi!
Ich habe z.B. zwei Windows-Forms, von denen eine (evtl. per Button-Click) die andere als .ShowDialog() aufruft. Auf dieser Form gibt es dann einen Button, der einfach eine Testexception wirft (throw new Exception("Test")).
Die andere Form fängt den Fehler per try-catch-Block auf und gibt dann eine entsprechende Fehlermeldung aus.
Das funktionniert einwandfrei, wenn ich das Programm unter VS starte. Gehe ich aber ins Projektverzeichnis, und starte die erzeugte .exe-Datei von Hand, dann kommt statt meiner Dialogbox die ich bei der Testexception haben möchte eine, die wie eine normal, nicht abgefangene Exception im Programm aussieht...
Warum fliegt die Exception in der .exe-Datei nicht von einer Form zurück in die andere??? Und kann ich das irgendwie ändern?
Gruß
Hm, das ist durchaus seltsam, allerdinngs vielleicht erklärbar!
Wird die ShowDialog-Methode in deiner HauptForm_Load-Methode aufgerufen?
Kannst du vielleicht mal etwas Quelltext zeigen?
--
mfg
Franksntein
Besuchen sie das VisualC++ - Forum
das ist wirklich seltsam.
ich habe das auch nachvollziehen können.
bei mir wird das form über ButtonClick geöffnet
Du kannst über das Application.ThreadException-Ereignis den Fehler generell abfangen, egal ob nun mit Debugger oder ohne. Ansonsten schon eine seltsame Angelegenheit.
([bb]|[^b]{2})
Einfach 2 Forms nehmen, je ein Button draufsetzen, und dann in der ersten Form im Klick-Event:
private void button1_Click(object sender, System.EventArgs e)
{
try
{
Form2 form = new Form2();
form.ShowDialog();
}
catch
{
MessageBox.Show("Error von Form gefangen!");
}
}
In der zweiten Form dann:
private void button1_Click(object sender, System.EventArgs e)
{
throw new Exception("Test");
}
Und unter VS geht das einwandfrei...
Nur die .exe Macht das dann nicht mehr!
@NoOneKnows
Hm...wie geht das denn mit dem Application.ThreadException-Ereignis???
Habs mal so probiert, aber da kam immer noch dasselbe!
Application.Run(new Form1());
Application.ThreadException+= new System.Threading.ThreadExceptionEventHandler(abfangen);
Original von confused
Application.Run(new Form1());
Application.ThreadException+= new System.Threading.ThreadExceptionEventHandler(abfangen);
Probiers mal in umgekehrter Reihenfolge 🙂
([bb]|[^b]{2})
Versuche nur mal zum Spass catch(Exception err). Ich denke zwar nicht, dass das die Ursache ist, aber es könnte sein, dass die Try-Catch bei der Optimierung vom Compiler verworfen wird.... (kann eingentlich nicht!).
Was du vielleicht noch machen könntest währe den ildasm hernehmen und die bin/release/*.exe mal dekompillieren....
--
mfg
Frankntsein
Besuchen sie das VisualC++ - Forum
Original von NoOneKnows
Du kannst über das Application.ThreadException-Ereignis den Fehler generell abfangen, egal ob nun mit Debugger oder ohne. Ansonsten schon eine seltsame Angelegenheit.
Damit catche ich dann alle Exceptions die sonst fliegen würde weg, ohne die Anwendung abzuschießen???
Besuchen sie das VisualC++ - Forum
@Franknstein:
Ja, damit sollte alle nicht durch Try-Catch behandelten Exceptions gefangen werden, die im Application-Thread auftreten. Ich hab in dem zusammenhang eben mal meinen eigenen Fehlerdialog programmiert und wollte nicht, daß irgendeine Fehlermedlung von dotnet kommt. Aus irgendwelchen Gründen hatte ich damals zur Sicherheit auch ein Try-Catch um das Application.Run() gemacht. Aber eigentlich sollte das überflüssig sein...
([bb]|[^b]{2})
sorgt ein Try-Catch um die Application.Run nicht für den Tod dieser, falls die Exception bis dahin fliegt?
--
mfg
Franknstein
Besuchen sie das VisualC++ - Forum
Eigentlich ja, aber es gibt da natürlich auch ein Trick:
bool exit = false;
MainForm form = new MainForm();
while (!exit)
{
try
{
Application.Run(form);
}
catch (Eception ex)
{
// Exception Handling
// evtl. exit = true;
}
}
Aber das Try-Catch fängt nicht alle Exceptions ab, daher sollte man das wenn überhaup nur als zusätzlichen Schutz verwenden. Ich glaub da gabs auch wieder unterschiede zu Visual Studio .NET Debugging und reiner Executable. Aus irgendnem Grund hatte ich das aber damals aber auch verwendet.
([bb]|[^b]{2})