Application.ThreadException Doesn't Work Right. Why?

  • Thread starter Thread starter James Hancock
  • Start date Start date
J

James Hancock

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
 
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
Click to expand...

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
 
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
 
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
Click to expand...

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
 
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 :)
Click to expand...

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!
 
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
 
Back
Top