Vanishing Exceptions

[Andrew Ducker]

My unhandled exceptions seem to just vanish. If I put the line:
int x = int.Parse("XXX");
in (which generates an exception, obviously) then the code that's
executing just vanishes, leaving me back at the form (which carries on
working). If I deliberately catch an error, I catch it just fine.

Stepping through it line by line, it runs to the exception generating
line, and then just doesn't execute anything beyond that line.

I've checked my Exceptions dialog, and CLR Exceptions are definitely
set to Break Into Debugger if Not Handled.

Any idea why unhandled errors might not do anything at all?


Andy D

 

[Guest]

I have seen cases (however I am never able to adequately reproduce them on
smaller scale) where when an exception occurs in a sub thread of my main app,
the thread just terminates. No CLR exception notice, just a note that the
thread has exited.

Where is the exception causing code occurring? Is it in your main thread or
something lower?

Brendan

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

There are couple of things to check, first are you doing that in a thread?
if so the UI will not receive it, you use AppDomain.UnhandledException or
Application.ThreadException

Also, check if you have your solution in debug mode, also check the project
properties to make sure you have optimization disabled.

cheers,

 

[Bruce Wood]

The calling regimen for WinForms works differently when running under
the debugger versus running independently. When _not_ running under the
debugger, in many instances your methods are called directly by Windows
rather than from where you think they should be called.

This can result in some strange run-time behaviour where exceptions are
concerned: some exceptions that are successfully caught by a
try...catch under the debugger take your app down outside the debugger.
If you look at the call stack you won't see the method that contains
the try...catch anywhere on the stack. Instead, you'll see your failing
code being called directly by Windows.

Another case is some exceptions that are trapped by a try...catch when
running under the debugger are caught instead by some generic
exception-handling code in a standard Windows form when running outside
the debugger. The form is designed to simply swallow exceptions and
keep running, which it does. (I use the PrintPreviewDialog, which does
this.)

Someone here once described in detail exactly how this works, but I
can't find the thread right now.

 

[Ludovic SOEUR]

If you are in a thread, you can use ThreadException or add try catch in your
thread and when an exception is caught, use Application.OnThreadException(e)
to trasmit it to the main thread.

Is it whith drag/drop operations ? I already had the same problem in the
main thread with drag/drop operation. When you use DragOver or DragDrop
event, windows surround your code with try catch. And if one exception
occurs, it doesn't transmit it.

Hope it helps,
Ludovic Soeur.

 

[Andrew Ducker]

It's in my main thread - but it only happens once the message pump
starts - i.e. if I call code as part of the initialisation of the main
code, exceptions are detected, but if the same code is called from a
button press then the exception just evaporates.

Andy D

 

[Andrew Ducker]

I've had a look, but can't find details. As I replied above:

"It's in my main thread - but it only happens once the message pump
starts - i.e. if I call code as part of the initialisation of the main
code, exceptions are detected, but if the same code is called from a
button press then the exception just evaporates."

Which makes it, indeed, sound like it's vanishing into the cracks in
Windows. I might just trap AppDomain.UnhandledException and see what
happens...

Cheers!

Andy D

 

[Andrew Ducker]

Darnit - should have held off on posting. I added the following to the
start of my code:

AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.UnhandledException +=new
UnhandledExceptionEventHandler(currentDomain_UnhandledException);
Application.ThreadException +=new
System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

and then put some Messageboxes into those methods. Neither of them
ever get called. Something wierd is definitely going on.

Andy D