Prev: how to catch error: cant open ADODB connection
Next: VBS and CDO.Message / Mapi.Session - which should I use
From: ekrengel on 15 Jun 2010 11:17
On Jun 15, 8:32 am, Tom Lavedas <tglba...(a)verizon.net> wrote:
> On Jun 15, 7:43 am, BigDaddyJim <hungerfo...(a)gmail.com> wrote:
>
>
>
> > How about a "On error resume next" at the top?  Couldn't hurt to try
> > for purposes of diagnosis.
>
> > Jim
>
> I think that's a decidedly LOUSY idea.  It can and does hurt to
> blanket a script with On Error Resume Next (though lots of sample
> scripts do it).  Because it makes troubleshooting HARDER.  With it in
> place, the true source of the problem is generally hidden.  Rather,
> the script tries to 'soldier on', with incorrect intermediate results,
> often with disastrous results - like corrupting data.  It leaves the
> user to wonder what happened, with likely misleading symptoms of the
> real problem.
>
> The only time it is justified, IMHO, is when a specific bit of code is
> targeted and specific error handling code is added to test the
> Err.Number and act accordingly.  In that way, the programmer
> anticipates errors and provides logical workarounds to keep the
> program on track (or asks the user to make the decision).
> _____________________
> Tom Lavedas

Yes exactly. I do use "On Error Resume Next" at some parts of the
script, but that is because of exactly what Tom just explained. If
you do use it, the error should always be cleared after the error has
been caught (that's if you want to continue with the script and catch
other errors in the same way).

Anyway, there really isn't anything wrong with the script as far as I
can see now...I was just being impatient. Unless someone can think of
a way to speed it up? =)
From: ekrengel on 16 Jun 2010 12:30
On Jun 15, 11:17 am, ekrengel <erickreng...(a)gmail.com> wrote:
> On Jun 15, 8:32 am, Tom Lavedas <tglba...(a)verizon.net> wrote:
>
>
>
> > On Jun 15, 7:43 am, BigDaddyJim <hungerfo...(a)gmail.com> wrote:
>
> > > How about a "On error resume next" at the top?  Couldn't hurt to try
> > > for purposes of diagnosis.
>
> > > Jim
>
> > I think that's a decidedly LOUSY idea.  It can and does hurt to
> > blanket a script with On Error Resume Next (though lots of sample
> > scripts do it).  Because it makes troubleshooting HARDER.  With it in
> > place, the true source of the problem is generally hidden.  Rather,
> > the script tries to 'soldier on', with incorrect intermediate results,
> > often with disastrous results - like corrupting data.  It leaves the
> > user to wonder what happened, with likely misleading symptoms of the
> > real problem.
>
> > The only time it is justified, IMHO, is when a specific bit of code is
> > targeted and specific error handling code is added to test the
> > Err.Number and act accordingly.  In that way, the programmer
> > anticipates errors and provides logical workarounds to keep the
> > program on track (or asks the user to make the decision).
> > _____________________
> > Tom Lavedas
>
> Yes exactly.  I do use "On Error Resume Next" at some parts of the
> script, but that is because of exactly what Tom just explained.  If
> you do use it, the error should always be cleared after the error has
> been caught (that's if you want to continue with the script and catch
> other errors in the same way).
>
> Anyway, there really isn't anything wrong with the script as far as I
> can see now...I was just being impatient.  Unless someone can think of
> a way to speed it up?  =)

Just an update...I found another method using "ExecQueryAsync", and it
was faster...but only by about 10 seconds =) Not enough to make a
difference.
First  |  Prev  | 
Pages: 1 2
Prev: how to catch error: cant open ADODB connection
Next: VBS and CDO.Message / Mapi.Session - which should I use