Application.ThreadException Doesn't Work Right. Why?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

James Hancock - 09 Feb 2005 18:46 GMT

Here's the problem that I'm having.

Our application in debug mode doesn't link in Application.ThreadException,
it only functions when in debug mode. (did this with a compile directive) so
that we get errors on the right error line etc. Makes everything easier for
debugging in debug mode. However in release mode, we use the
Application.ThreadException to handle errors.

Now in debug mode, periodically I get errors (mostly SQL Server errors
because of typos in query strings) that error back to the Application.Run
line instead of the line happened. Really really frustrating, but I can
live with it if I must.

However sometimes (not all, but more than half) of any SQL Exceptions that
get thrown in release mode don't get caught by Application.ThreadException
and the application jsut disappears off of the person's screen and they have
to restart it and we don't get any information.

I thought at first it was because the SQL errors were being thrown in a
separate DLL (that is strongly referenced) but that doesn't appear to be
correct. It also happens when filling a Data Adapter on a form in our
application directly.

Anyone have any ideas as to why this is happening? (it doesn't seem to
happen on any other type of error, but that might be becuase most of our
errors are SQL typos, not other real big problems.)

Thanks,
James Hancock

Reply to this Message

Sunny - 09 Feb 2005 20:55 GMT

> Here's the problem that I'm having.
>
[quoted text clipped - 25 lines]
> Thanks,
> James Hancock

James, while I do not know your exact problem, please note that
Application.ThreadException was not meant for general purpose exception
handling. Use appropriate try/catch blocks in your code wherever
possible, instead of relaying on some general handling.

The whole idea of exception handling is to give you the opportunity to
recover safely. Put every SQL call in try/catch, so you can do whatever
is needed if it fail.

Sunny

Reply to this Message

James Hancock - 09 Feb 2005 22:46 GMT

I understand that, but what this is, is if any exception that is unintended
happens, we trap it along with all of the stack information etc. and send it
to us via a web service. End result is that we can fix bugs instead of
having to actually have customers that know what they did 5 seconds ago
(which doesn't happen) and spending 2 hours on the phone with them to try
and figure out what is going on.

It USED TO work, but stopped, and we can't figure out what stopped it.
There should never be a case where an exception just causes the application
to disappear, it should at the very least get a notfication in windows or a
debugger error or SOMETHING. We're getting absolutely nothing.

James Hancock

>> Here's the problem that I'm having.
>>
[quoted text clipped - 42 lines]
>
> Sunny

Reply to this Message

Sunny - 10 Feb 2005 00:26 GMT

> I understand that, but what this is, is if any exception that is unintended
> happens, we trap it along with all of the stack information etc. and send it
[quoted text clipped - 9 lines]
>
> James Hancock

Unfortunately it depends where and how the exception happen, and what
caused it. For sure you have to try using Appdomain.UnhandledException
as well. And also, what if in this handler the communication to your
service fail as well? I prefer to write a simple text log file, and to
ask the user to send it to me, when I need it. I do not relay on their
memory as well :)

Sunny

Reply to this Message

James Hancock - 10 Feb 2005 05:30 GMT

> Unfortunately it depends where and how the exception happen, and what
> caused it. For sure you have to try using Appdomain.UnhandledException
> as well. And also, what if in this handler the communication to your
> service fail as well? I prefer to write a simple text log file, and to
> ask the user to send it to me, when I need it. I do not relay on their
> memory as well :)

We fall back to a written log file and ask them to email the log file to us
if they have no internet connection.

I'll try also implimenting appdomain.unhnaldedexcpetion and see if that gets
the rest of it. Thanks!

Reply to this Message

Matt Garven - 10 Feb 2005 05:57 GMT

Have you tried also hooking into AppDomain.UnhandledException?

ie:
Application.ThreadException += new
ThreadExceptionEventHandler(HandleThreadException);
AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(HandleUnhandledException);

We have a similar style of error reporting to you (by the sound of it), but
we have handlers for both ThreadException and UnhandledException as above.
The only exceptions that this doesn't catch are things like
ExecutionEngineExceptions, some StackOverflowExceptions, etc.

Hope this helps.

Regards,
Matt

> Here's the problem that I'm having.
>
[quoted text clipped - 25 lines]
> Thanks,
> James Hancock

Reply to this Message

Application.ThreadException Doesn't Work Right. Why?

Free Magazines