Re: Thoughts on current error handling best practice with VBScript


"Anthony Jones" <Ant@xxxxxxxxxxxxxxxx> wrote in message
news:Oylt1wlZIHA.1212@xxxxxxxxxxxxxxxxxxxxxxx
"FUBARinSFO" <file1303@xxxxxxxxx> wrote in message
news:7a2f0ed5-6af3-4b4e-a523-244cb17942cf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Folks:

<snip>

2. Defensive programming

Anthony Jones also recommends not using VBS if you're concerned about
error handling. I was afraid of that. I always use Option Explicit,
and do try to wrap possible exceptions in some sort of error-handling
code. But even using try-catch is a stretch for some of us, so if I
am in any way representative of the casual programmer it is a constant
struggle to set up your code to handle exceptions On Error ... is
something I used to use, but found it bothersome. That is my
mistake. I used to program from templates that I called up with pre-
formed structure, but have fallen off the wagon on this. All of these
comments make me think that if I'm serious about this I should
reactivate my templates and have another go at that method.


It isn't really reasonable to expect a 'casual programmer' to program
defensively. VBScript and its kin have encouraged a great deal of
'casual'
programming which is the reason why it has been so successful and the
reason
many 'casual' programmers achieve their aims successfully.

However the comes a point where a requirement has sufficient complexity
where the 'casual' approach just isn't sufficient. Then one of two things
happen:

1) the casual programmer becomes aware of the current approaches
limitations
and sees the need climb a learning curve for what seems only a little
payback (after all what has gone on before has been successful).

2) the casual programmer remains unaware that the current approaches have
limitations and struggles to achieve the requirement. Something is
delivered but its fragile and needs hand holding and frequent maintenance
to
continue working. Eventually it suffers from 'modification fatigue' and
breaks down completely.

The above two scenarios do not refer simply to the transition from casual to
defensive, but from casual to, well, non-casual. That implies, among other
things, the application of a consistent structure to one's scripts, and the
anticipation of the sorts of "exceptional conditions" that could reasonably
arise. Taking a casual script that includes no error handling and fixing it
by sticking in extra error handling code is a patch-work approach at best.

Often the possibilities for exceptional conditions arise out of assumptions
made, consciously or otherwise. Before patching code based on such
assumptions, it is often useful to determine the assumptions made and
critically analyse them.

I think the word "error" in the term "error handling" often has the wrong
effect, as it makes us thing that things are wrong or incorrect. Certainly
if your code attempts to create a file in a non-existent folder, it will not
result in the successful creation of that file. If ignored, that might cause
other problems later on for the script.

But the lack of the folder in and of itself should not be considered an
error, just a condition, possibly an unexpected or undesired one. In some
contexts it could mean there is a definite misconfiguration of a computer,
which might be an error that might require some corrective action be taken
outside of the scope of your script. But if you take the possibility of a
folder's non-existence into account, you will find that it may not always be
an error in every case. One of my scripts routinely creates files in
non-existing folders - by creating them as required. The purpose of that
script is to generate a series of log files in a hierarchical folder
structure that is created as needed. In this context, the non-existence of a
folder is not an error, but an anticipated event.


Ekkehard Horner pretty much captures my take on the spirit of On Error
Resume Next when he remarks that "That is like driving with closed
eyes to avoid being dazzled by the headlights of other cars."

Reading these resources, it's clear I'm going to have to incorporate
On Error into my programs if I want to have more than a trivial error
handling regime.


To be frank the only non-trivial way to do error handling in VBScript is
to
use Resume Next and test Err.Number after every statement (or at least
every
statement that has reasonable chance of failing). Real ugly.

Certainly not pretty, by a long shot. But better than anticipating and
testing for all of the possible conditions that could cause an operation to
fail. I think it better to let the error object tell you why the file
creation failed, rather than checking first that the folder exists (it could
still be deleted before your code gets to the point of failure), that you
have access to it (that could change), that the computer is online (it could
go offline), etc.etc.

Using resume next, err.clear (!), and err.number literally in code can
certainly obscure the logic of what the script is supposed to do when
conditions allow. Sometimes it is better to limit these to the lower level
routines, where they can be allowed to to their work uninterrupted and
forgotten about. Subs and Functions are for finer levels of detail, and what
is error checking if not a detail?

4. Example code styles

I gave an example of a little wrapper I've started using in my code,
to protect against file I/O errors. Ekkehard gives many more examples
of coding style, one of which I had never seen before: a coherent
reason for using a multi-statement line. It used to be that you did
this in BASIC to save program memory. I always thought it made the
code uneditable. But he has Dimed the variable as he uses it, in the
below lines from his posting:

Dim sFSpec : sFSpec = "c:\exchange\data\20080201\maynotbethere.txt"
Dim oTS : Set oTS = oFS.OpenTextFile( sFSpec )
Dim bOk : bOk = False

I'll have to experiment with that, as my style is to place all vars up
front, no matter where they're used, which makes for some awkward
jumping around. But he has the same economy of naming that I prefer:
'o' rather than 'obj' for object, 'b' rather than 'bln' for boolean,
's' rather than 'str' for string, and so forth - against VBS
recommended naming practice, but far preferable imho.

I also use what I like to refer to as 'slob' prefixing. String, Long,
Object and Boolean. They cover probably about 90% of all variables
created.
I stick with byt, sng, dbl for the rare times I use them.

I also use g for global scope, m for module scope (only in classes in
VBScript), r for ByRef parameters, v for ByVal parameters and c for
constants (I hate those shouty all upper constant names).

However some really common objects like FileSystemObject get fso or gfso
(if
instanced globally).

We all have our style preferences. I, for example, have a philosophical
dislike of RPN prefixing, although I do have a few of my own prefixes to
indicate certain things. Without starting a religious war over this, I think
I can safely say that, at least for the casual scripter, the style that is
best is the one that he finds the most useful.

Overall, I really want to thank the three of you for your thoughtful
comments. This is great stuff. I'm going to mush along a bit longer
in VBS and incorporate your suggestions, but will be spending more
time in the future looking for a way to get the same work done (in
another language) that has error handling as a more intrinsic feature
of the language.

Agreed. this has been an interesting thread for such a short one, with some
good practical input from Anthony, Paul, and Ekkehard.

/Al


.

Relevant Pages

  • Re: Thoughts on current error handling best practice with VBScript
    ... you should be looking to JScript for structured error handling. ... am in any way representative of the casual programmer it is a constant ... It isn't really reasonable to expect a 'casual programmer' to program ... Structured error handling is the recommended method. ...
    (microsoft.public.scripting.vbscript)
  • Re: Thoughts on current error handling best practice with VBScript
    ... Anthony Jones also recommends not using VBS if you're concerned about ... Dim sVal ... impression about how much of an afterthought error handling has been ... you've run the script from an open command window, using cscript, Ctrl- ...
    (microsoft.public.scripting.vbscript)
  • Re: Automated changing of local admin password on workstations?
    ... Funny coincidence....I just built a script yesterday for that exact same ... ' Create the file system object to handle input file operations ... 'Obtain the administrative account name from the user ... ' Error handling to trap lazy users inputting a null account name ...
    (microsoft.public.windows.group_policy)
  • Re: slow logon
    ... > we have symantec av 10 and yes the software looks for updates from a> local ... > i told the programmer that the domain controller at each site will> check ... > update the time for the clients that talk to the dc as the logon> server. ... >>> We have a Start up script and a login script for users as well as ...
    (microsoft.public.windows.server.active_directory)
  • Re: Error Handling
    ... > Exit Function ... > What I'm confused on is error handling in vbs. ... > processing the script, which I don't want it to do. ...
    (microsoft.public.windows.server.scripting)