Error Logic Suggestions Needed

[BGCSOCAL]

Last fall I was developing a proof of concept even though I'm not really a
programmer. It worked so well that now they want to make it a production
program. I put very little error logic in it and it runs fine on my PC, but
errors out on the server where I installed it. Obviously I need to bulk up my
error logic so I can find out what is wrong. I used to use an "on error goto"
at the top of the old VB 6 programs but, when reading about error logic for
VB2005, it stated more than once that this shouldn't be used. The program
accesses a database and a spreadsheet literally 100's of times. Do I really
need to add a TRY for every one of those? Are there any alternatives? Does
VB2005 have some kind of overall/default error processing that applies to
everything anymore?

 

[Patrice]

For example see :
http://msmvps.com/blogs/deborahk/archive/2009/09/02/global-exception-handler-winforms.aspx

You can start by creating a global exception handler that will be your
"safety net".

Then you can use a local using statement
(http://msdn.microsoft.com/en-us/library/htd05whh(VS.80).aspx) to allow
releasing ressources in case of an error (but still have error reporting
processed by your global handler).

And finally, you can also use a local try/catch if you want to process a
particular error from which you expect to be able to recover...

 

[Armin Zingler]

Last fall I was developing a proof of concept even though I'm not really a
programmer. It worked so well that now they want to make it a production
program. I put very little error logic in it and it runs fine on my PC, but
errors out on the server where I installed it. Obviously I need to bulk up my
error logic so I can find out what is wrong. I used to use an "on error goto"
at the top of the old VB 6 programs but, when reading about error logic for
VB2005, it stated more than once that this shouldn't be used. The program
accesses a database and a spreadsheet literally 100's of times. Do I really
need to add a TRY for every one of those? Are there any alternatives? Does
VB2005 have some kind of overall/default error processing that applies to
everything anymore?

In addition to individual error handling where required - where, how and
what is handled is, well, individual - I have a Try-Catch around the code
in every thread's main procdedure handling the "unexpected" errors.
Does this answer your question?

 

[OmegaSquared]

Hello, Bettie,

I believe that "On Error..." is still available in VB2005, and there may be
some cases where it provides advantages over structured exception handling.
(Personally, I haven't found any occasion to use "On Error..." since leaving
VB6.)

It is definitely preferable to consider and include exception handling when
you design your code, but you should be able to retrofit some useful
exception handling after the fact. Exceptions will "bubble up" the call
stack until an active exception handler is located, so a few high level
exception handlers may be all that you need.

To locate and diagnose errors easily, you may find it helpful to include the
exception's StackTrace property in an error report. Recording the error
report in a file that the user can send to you will help with clear
communication of the details.

By the way, and just as general comment, it has been my experience that
there is no gain to be had by taking shortcuts when creating
"proof-of-concept" or "one-time-use" programs. If the code is useful, it
will inevitably be used over and over, expanded and developed. Poor
structure and techniques associated with the shortcuts taken in the
"prototype" tend to live forever, and forever cause the maintenance
programmer headaches and the owner additional expense. So, in making this a
production program, you may want to consider a complete re-write.

Cheers,
Randy

 

[Cor Ligthert[MVP]]

A kind of bad habit in VB6 was to put every where ON Error etc.

You should only use error catching if there can be an error.

For instance if a field can be nothing, then test it first if it is not
nothing, you are able to do that in Net, so use it.

jmho

Cor

 

[Gregory A. Beamer]

Last fall I was developing a proof of concept even though I'm not
really a programmer. It worked so well that now they want to make it a
production program. I put very little error logic in it and it runs
fine on my PC, but errors out on the server where I installed it.

Is this a windows app or a web app? If it is a windows app, what do you
mean "installed on server"? Is it run on the server? Or is it
downloadble from a server?

Obviously I need to bulk up my error logic so I can find out what is
wrong. I used to use an "on error goto" at the top of the old VB 6
programs but, when reading about error logic for VB2005, it stated
more than once that this shouldn't be used.

In general, the "on error go to hell everywhere" approach was frowned on
in VB, as well, although it was widely adopted, as it was easy. The
preferred method was to write individual handlers for routines. The
overarching was often left to catch bad programming constructs.

The program
accesses a database and a spreadsheet literally 100's of times. Do I
really need to add a TRY for every one of those?

you need to separate out the data access logic and place the try ...
catch there. You then call the data access layer from your thousands of
places.

Are there any
alternatives? Does VB2005 have some kind of overall/default error
processing that applies to everything anymore?

You can still do this, but it becomes a last ditch effort just like the
"on error go to hell everywhere" handler in classic VB.

To debug what is going on here, assuming a windows app for example, you
can place a try ... catch around the startup mechanism and find the
error.

Tracing is also useful, as you can find problems by tracing the right
elements. It is often more useful in production systems than the generic
catch all error handler.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[BGCSOCAL]

Thank you for the input. they just asked me to develop another proof of
concept program. I suggested a professional developer, but every just
laughed. I was serious. Still, I think you are right on. this time I will
develop it like it is going to work forever; i.e., from the very start.

 

[BGCSOCAL]

I'm not sure. So you put a try/catch at the beginning of a procesdure (or
whatever) to catch what you didn't code for. Can you nest try/catch groups?

 

[BGCSOCAL]

thank you for the input. I will read thea rticles that you suggested.

 

[BGCSOCAL]

Thank you for your reply. I see your point. Check that data from spreadsheeet
/database is actually there if it is required. that makes sense. It will take
longer to implement but I see why it is better.

 

[BGCSOCAL]

Thank you for replying. So you are saying use data and try/catches where
there is more likelihood of failure. If something else occurs, the use the
trace to track the error down. That's makes good sense.

 

[Armin Zingler]

I'm not sure. So you put a try/catch at the beginning of a procesdure (or
whatever) to catch what you didn't code for.

I'm afraid, I don't know what "catch what you didn't code for" means in
this context.

I use SEH (structured exception handling) where I think it makes sense.
However, this is never for catching programming faults. The only
safety net for them is the Try-Catch in each thread's main procedure
just to use my own standardized error handling (includes writing
to a log file etc).

Some exceptions can be handled by throwing another exception giving
more information about the location or task where the error occured
and carrying the original exception as it's InnerException.
For example, in a multi-step operation, you can individually handle
each step by providing different error descriptions.

And, user input must never lead to exceptions. However, for example,
before there were the TryParse methods, calling the Parse method
surrounded by a Try-Catch was the only to validate user input
(the only one if you wanted to use the Parse method).

Can you nest try/catch groups?

yes



Maybe of interest: (Only found but didn't read it and consequently
can't say if I agree)
http://msdn.microsoft.com/en-us/library/seyhszts.aspx

 

[BGCSOCAL]

I've been looking up the try/catch mechanism as you all suggested. From some
of the reponses I got the idea that an error bubbles up to the highest level.
So, If I put a Try/catch around the works of the main logic (the part that
calls the subroutines) would it pick up the errors from the lower levels? Or
is it best to go down to the next level and put a try/catch in every
subroutine? Or is it best to put it in every subroutine in the program.

 

[Armin Zingler]

I've been looking up the try/catch mechanism as you all suggested. From some
of the reponses I got the idea that an error bubbles up to the highest level.
Right.

So, If I put a Try/catch around the works of the main logic (the part that
calls the subroutines) would it pick up the errors from the lower levels?
Yes.

Or
is it best to go down to the next level and put a try/catch in every
subroutine?

What would you do with the exception in every function?

Or is it best to put it in every subroutine in the program.

No. (IMO)

 

[BGCSOCAL]

I've done research on the try/catch logic you all suggested and read a bunch
more articles. Apparently, errors from one subroutine bubble up to the
calling routine and can be handled there. So, is the best way to put a
try/catch around the main routine to catch errors from all of the subroutines
that it calls, or is it better to put one try cactch in each subroutine?

It seems like if you use the Message and the StackTrace properties that it
will pinpoint what the error is and where it occurred. Good idea or bad?

 

[Phill W.]

I've been looking up the try/catch mechanism as you all suggested. From some
of the reponses I got the idea that an error bubbles up to the highest level.
So, If I put a Try/catch around the works of the main logic (the part that
calls the subroutines) would it pick up the errors from the lower levels? Or
is it best to go down to the next level and put a try/catch in every
subroutine? Or is it best to put it in every subroutine in the program.

General Rule: Put Catches where you can do something "useful".

If you /only/ have the top-level catch, then pretty much all you can do
is log the error (to a file [for later] /and/ to the screen) and kill
the program.

If you dig down deeper into the logic, you can /recover/ from errors or
clean the "mess", before continuing, for example

Try
Dim sr as new StreamReader( "file", ... )
Dim sData as String = sr.ReadToEnd()
. . .
sr.Close()
Return sData

Catch ex as IO.FileNotFoundException
LogToFile( ex )
MsgBox( "That file doesn't exist ", ... )
Return Nothing

End Try

HTH,
Phill W.

 

[BGCSOCAL]

Thanks!
--
Bettie

What would you do with the exception in every function?


No. (IMO)