Why is "Unhandled Exception" thrown within a Try-Catch block?

[Jerad Rose]

There are many things that confuse me about the way .NET handles errors and
was hoping somebody could shed some light on my confusion:

1) Why are some errors treated differently? For example, some errors seem
to be handled as expected by the Try-Catch blocks. But some throw an
"Unhandled Exception" in the JIT debugging window, and some in the normal
IDE Continue-Break window -- even when within a Try-Catch block. I've read
that this was fixed by compiling your app in Release Mode, but I tried this
and had no effect on error handling. The JIT window is shown and the app
continues until I end the task through the task manager.

2) I've read about the global "ThreadException" event, but this seems like a
very poor practice, as it catches errors at a global level, and you are
unable to handle them at the level to handle each exception separately. I
know this is a good "last resort" catch-all method, but I would much rather
be able to handle them on an individual basis. Is this not possible for
these "Unhandled Exceptions"? Or am I misunderstanding how the
ThreadException event works?

3) Where did "JIT" debugging come from, and how the heck do you get rid of
it? I like the fact that it shows you the stack trace, but since the app
continues, it renders the JIT window non-responsive, and I'm unable to view
the details of the error nor click any buttons (Stop/Continue).

I realize that I may be misunderstanding much about the error handling
methods of .NET, so if you have any good resources for learning about this
stuff, please let me know.

Thanks in advance for your help.

 

[steve]

exceptions are objects. there are specific types that have common interfaces
among them all but have different implementations. typically, a try/catch
where you catch system.exeception will catch most all errors w/n a block of
executing code (not globally; only for that method/property). if you want to
catch only a specific type of error then you can "catch" just that
error...i.e. catch ex as sql.exception (or whatever) vs. catch ex as
system.exception. this allows you greater control over what actions you need
to take to resolve the error and make maintaining the code much more
concise - as it pertains to error handling.

the best places to find info about error handling are msdn (has a ton of
info on exceptions for vb.6- converts) and, as always, a book at your local
bookstore.

hth,

steve

 

[Jerad Rose]

Thanks Steve for your reply. I believe this has put me on the track I need
to be headed to nail this stuff down. As you probably figured, I am used to
the VB6 way of error handling, and it is taking some time to get used to the
newer structured way of error handling.

I am still a little confused on the Just-in-time debugging though -- I'm
thinking this is not a Microsoft feature, and if so, I'm assuming MSDN
articles (which is where I'm starting) will not touch on. I have done some
research on this in the past, but I can't seem to find any info on how it
relates to .NET specifically. So any additional info from anybody on this
would be appreciated.

Thanks again for the responses.

 

[Fredrik Melin]

My experience for #1 and 2, you need to have a global thread exception event
taking care of some errors.
There is bugs with listviews and other items, that happens when you use the
mouse, there is no surrounding code, therefore no try catch block around it.

Regards
Fredrik Melin