Help on debugging application after release

  • Thread starter Thread starter jd_ie
  • Start date Start date
J

jd_ie

Hi all,

We have written an application for Windows CE .NET whose data will be
very important and cannot be lost. During on-the-road testing, we had a
couple of unhandled exceptions occur, and the exception did not happen
every time the same operation was carried out, so it is difficult to
know why it happened, especially as it was a user relaying the
information through someone else to me, and one cannot be sure of the
reliability of the information.

The problem is that if an unhandheld exception occurs, there is no
information about the exception shown.

I was thinking of using log files to log exception error messages and
types (even though the line number is not accessible in the Compact
Framework), whenever an exception occurs. I could enclose try blocks
around all SQL operations, as these seem to be a likely place for
exceptions to occur. In this case I could also write the SQL statement
to the log file, which would do a good job of identifying the possible
location of the error. The problem is how to catch the other
exceptions.

In Visual Basic (which I used to program in) in every function one
could put a "On Error Goto ErrHandler" statement at the top, and then
at the end put error handling code where code for writing the error
details to a log could be put. I suppose that to at least find the
function in which the error occurred, I could in every function enclose
the code in one big try block, and put the catch at the end, but would
this in any way affect performance? Also I feel that this is not good
programming style, is this correct? I have not been programming in C#
long.

Are these the only options open to me? What is the best way to use try
blocks to catch exceptions when you want to be able to catch all
exceptions and find out where they occurred?

I understand that there may be a bug in the code that will only
manifest itself when in the complex working environment, but I would
feel better about it if I could be relatively sure that the first time
an exception occurrs, that I could be reasonably sure about having
enough information to fix it.

It worries me that we might be in the dark and helpless to effectively
fix these problems. Is anyone else in this situation; does anyone know
the best way to approach this? I would sincerely appreciate your help.

Best regards,

Jonathan Dudley
 
Hello jd_ie:
jd_ie said:
Hi all,

We have written an application for Windows CE .NET whose data will be
very important and cannot be lost. During on-the-road testing, we had a
couple of unhandled exceptions occur, and the exception did not happen
every time the same operation was carried out, so it is difficult to
know why it happened, especially as it was a user relaying the
information through someone else to me, and one cannot be sure of the
reliability of the information.

The problem is that if an unhandheld exception occurs, there is no
information about the exception shown.
Click to expand...

--ONe really nice tool is log4net which has compact framework support. THe
really nice feature is that you can log messages at many different levels so
you can finely tune what you are logging and when you log it.
http://logging.apache.org/log4net/
I was thinking of using log files to log exception error messages and
types (even though the line number is not accessible in the Compact
Framework), whenever an exception occurs. I could enclose try blocks
around all SQL operations, as these seem to be a likely place for
exceptions to occur. In this case I could also write the SQL statement
to the log file, which would do a good job of identifying the possible
location of the error. The problem is how to catch the other
exceptions.
Click to expand...
--YOu can add a handler for a ThreadException so that when anything happens
on the main thread, it's caught by it
http://msdn.microsoft.com/library/d...formsapplicationclassthreadexceptiontopic.asp
In Visual Basic (which I used to program in) in every function one
could put a "On Error Goto ErrHandler" statement at the top, and then
at the end put error handling code where code for writing the error
details to a log could be put. I suppose that to at least find the
function in which the error occurred, I could in every function enclose
the code in one big try block, and put the catch at the end, but would
this in any way affect performance?
Click to expand...
The performance hit is marginal if you do this, but there's a ton of other
reasons to avoid this approach.

Also I feel that this is not good
programming style, is this correct?
Click to expand...
--It's terrible programming style. Typically you only want to trap a line
or two and then respond to it. As a rule, if you aren't going to do
something specific to handle an exception, don't catch it. There are
exceptions to this (no pun intended) but they are few and far between and as
a rule, the above holds.
I have not been programming in C#
long.

Are these the only options open to me? What is the best way to use try
blocks to catch exceptions when you want to be able to catch all
exceptions and find out where they occurred?
Click to expand...
The thread exception is definitely an approach that will get you most of
what you want. You can also create custom exception classes that will give
you more information about what happened. In addition, make sure you
override ToString() on your objects so that you can call it and get
meaningful information about the state of your objects.
I understand that there may be a bug in the code that will only
manifest itself when in the complex working environment, but I would
feel better about it if I could be relatively sure that the first time
an exception occurrs, that I could be reasonably sure about having
enough information to fix it.

It worries me that we might be in the dark and helpless to effectively
fix these problems. Is anyone else in this situation; does anyone know
the best way to approach this? I would sincerely appreciate your help.
Click to expand...
Handling exceptions is totally different from knowing about them. Exceptions
should happen in a manner that you know about. They aren't there to just
keep the program runnign although that's how they are used. By Handling
exceptions explicitly, you have to really think about your code and what can
go wrong, as well as how you want to respond when the conditions occur.
Jeffery Richter has a ton of articles on MSDN about this and has written
extensively on the subject. I couldn't possibly explain all of the nuances
of exception handling strategies here, but I'd read through his stuff as
well as getting his book on the .NET Framework (google on Jeffrey Richter
Exception ) and you'll find a bunch.

HTH,

Bill
 
My mistake. Sorry about that.
Sergey Bogdanov said:
--YOu can add a handler for a ThreadException so that when anything
happens
on the main thread, it's caught by it
http://msdn.microsoft.com/library/d...formsapplicationclassthreadexceptiontopic.asp
Click to expand...

Nope, it can't be caught by ThreadException :- only supported in .NET
Framework 2.0, 1.1, 1.0...


--
Sergey Bogdanov [.NET CF MVP, MCSD]
http://www.sergeybogdanov.com


W.G. Ryan MVP said:
Hello jd_ie:



--ONe really nice tool is log4net which has compact framework support.
THe really nice feature is that you can log messages at many different
levels so you can finely tune what you are logging and when you log it.
http://logging.apache.org/log4net/


The performance hit is marginal if you do this, but there's a ton of
other reasons to avoid this approach.

Also I feel that this is not good


--It's terrible programming style. Typically you only want to trap a
line or two and then respond to it. As a rule, if you aren't going to do
something specific to handle an exception, don't catch it. There are
exceptions to this (no pun intended) but they are few and far between and
as a rule, the above holds.
I have not been programming in C#


The thread exception is definitely an approach that will get you most of
what you want. You can also create custom exception classes that will
give you more information about what happened. In addition, make sure
you override ToString() on your objects so that you can call it and get
meaningful information about the state of your objects.
Click to expand...
Click to expand...
 
Back
Top