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? 
-- 
Bettie

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...

--
Patrice

"BGCSOCAL" <BGCSOCAL@discussions.microsoft.com> a écrit dans le message de 
news:6B00A7D4-35AA-4250-8396-FB3D02D0F42A@microsoft.com...
> 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?
> -- 
> Bettie 

BGCSOCAL schrieb:
> 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?

-- 
Armin

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

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

"BGCSOCAL" <BGCSOCAL@discussions.microsoft.com> wrote in message 
news:6B00A7D4-35AA-4250-8396-FB3D02D0F42A@microsoft.com...
> 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?
> -- 
> Bettie 

=?Utf-8?B?QkdDU09DQUw=?= <BGCSOCAL@discussions.microsoft.com> wrote in
news:6B00A7D4-35AA-4250-8396-FB3D02D0F42A@microsoft.com: 

> 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!             |
*******************************************

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.
-- 
Bettie


"OmegaSquared" wrote:

> 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
> 

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?
-- 
Bettie


"Armin Zingler" wrote:

> BGCSOCAL schrieb:
> > 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?
> 
> -- 
> Armin
> 
> 
> 
> .
> 

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


"Patrice" wrote:

> 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...
> 
> --
> Patrice
> 
> "BGCSOCAL" <BGCSOCAL@discussions.microsoft.com> a écrit dans le message de 
> news:6B00A7D4-35AA-4250-8396-FB3D02D0F42A@microsoft.com...
> > 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?
> > -- 
> > Bettie 
> 
> .
> 

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.
-- 
Bettie


"Cor Ligthert[MVP]" wrote:

> 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
> 
> "BGCSOCAL" <BGCSOCAL@discussions.microsoft.com> wrote in message 
> news:6B00A7D4-35AA-4250-8396-FB3D02D0F42A@microsoft.com...
> > 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?
> > -- 
> > Bettie 
> 
> .
> 

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.
-- 
Bettie


"Gregory A. Beamer" wrote:

> =?Utf-8?B?QkdDU09DQUw=?= <BGCSOCAL@discussions.microsoft.com> wrote in
> news:6B00A7D4-35AA-4250-8396-FB3D02D0F42A@microsoft.com: 
> 
> > 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 schrieb:
> 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

-- 
Armin

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.
-- 
Bettie


"BGCSOCAL" wrote:

> 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? 
> -- 
> Bettie

BGCSOCAL schrieb:
> 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)

-- 
Armin

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?
-- 
Bettie


"BGCSOCAL" wrote:

> 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? 
> -- 
> Bettie

BGCSOCAL wrote:

> 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.

Thanks!
-- 
Bettie


"Armin Zingler" wrote:

> BGCSOCAL schrieb:
> > 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)
> 
> -- 
> Armin
> 
> .
>