Post by FUBARinSFOThese are quite thoughtful submissions. My comments here will not do
them justice, I'm afraid.
1. Powershell (Monad) (from Anthony Jones)
I've seen references to it, but thought it was a third-party app.
Googling "what is powershell" I came eventually to this interview.
Unfortunately the interviewer is clueless, but Snover is an
evangelist.
Jeffrey Snover - Monad explained
Posted by The Channel 9 Team // Sun, Jun 24, 2007 4:49 PM
http://channel9.msdn.com/ShowPost.aspx?PostID=26795#26795.
Since I personally still use the command line for a lot of work, I am
very receptive to this pitch. Years ago the lack of a "unique" filter
(output unique lines from a text file) led me to write my own in
assembly language to take the piped output from sort. The toolbox
mode is still a great way to get work done. I still drop to command
window to use "dir" to filter and organize file names and folders.
It appears that here the effort is to integrate the CLI with the GUI
and provide a sort of grand synthesis of all current technologies.
The problem is that it requires what is a major effort to master yet
another environment - think Java. "There's lots of great systems out
there". True - and here is another. The mention of "curly
brackets" (otherwise known as braces) being embraced by the team
turned me off, I'm afraid - I'm not a fan of context-free grammar (a
boon to compiler writers) and find the braces more annoying than
helpful. Nowhere is "open systems" mentioned in the interview, so
presumably this is a proprietary Microsoft environment, extending C#
and .NET technologies. And neither is "error handling" - my main
concern at this point.
So as predisposed as I am to this message, I'll have to put aside
enough time (a week or two, at least) to get up to speed and write
some useful stuff before I'm ready to even begin to use this
environment. But thank you for the pointer, which I wouldn't have
otherwise pursued but for your thoughtful post.
Powershell is the script language for the .NET age of MS. I'm surprised
your searching has turned up such little results see:-
http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
I feel the same about {} as you, it was a useful shortcut to a compilier
back in the days when nightly builds were necessary cos it took all night to
do the build. However, { } is well embedded in programmer psyche now and
you do become used to it fairly rapidly.
I'm not sure I understand your comment re 'open systems' if that is a
consideration what are you doing using VBScript? Powershell is primarily
aimed and windows administrative tasks so being 'open' would hardly be an
advantage. As I mentioned if your intent is not administrative tasks then
you should be looking to JScript for structured error handling.
Another alternative would be Python.
Post by FUBARinSFO2. 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.
It sounds like a template approach can help but I'm not sure I understand
what you mean by 'template'. I've seen the 'casual' programmer cut'n'paste
existing code and tweak it to do what they want it to without understanding
how the program as whole wortks, is this what you mean?
Post by FUBARinSFO3. On Error Resume Next/ GoTo 0
Paul Randall has suggested reading the remarks in the script56.chm
file concerning the On Error statement. It brings back my long-ago
impression about how much of an afterthought error handling has been
for the BASIC developers. A single snippet of code, with no context,
serves as the only example of On Error Resume Next. No example of On
Error GoTo 0, let alone On Error GoTo <label of error handler>. Due
caution is mentioned that results are unpredictable depending on the
host environment if you don't have On Error statements in your code.
I found a better starting reference for this construct in the on the
Unstructured Exception Handling Overview
http://msdn2.microsoft.com/en-us/library/sf1hwa21(VS.80).aspx
Here at least there are examples, and honesty in advertising by
Note
Unstructured error handling using On Error can degrade application
performance and result in code that is difficult to debug and
maintain. Structured error handling is the recommended method. For
more information, see Structured Exception Handling Overview for
Visual Basic.
http://msdn2.microsoft.com/en-us/library/8a9f2ew0(VS.80).aspx
- which takes us back to the Try - Catch - Finally construct.
What I find particularly interesting is that none of these sources
make note of the possibility that if you have a runaway script, say,
you won't be able to break out of it with Ctrl-Break or Ctrl-C. If
you've run the script from an open command window, using cscript, Ctrl-
Break/Ctrl-C will work to break script execution. But if you've
started the script from the Windows shell, double clicking on the .vbs
file from Windows Explorer, you can't abort script execution except by
killing the task inside Task Manager. This is the problem that got me
started on this path in the first place, and I am somewhat surprised
to have found it hardly mentioned. There used to be a Ctrl-Break
handler in BASIC (wasn't there?), but was used to turn it off.
Evidently it's turned off in VBS now permanently, or else Windows
Explorer doesn't pass it any keystrokes.
In windows not all applications are attached to some kind of console from
which a Ctrl-Break etc can be recieved. You can kill process in task
manager. Structured error handling won't help eliminate infinite loops in
code though.
Post by FUBARinSFOEkkehard 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.
Post by FUBARinSFO4. 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
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
'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).
E.g.
Const gclMaxThingyCount = 50
Dim gfso : Set gfso = CreateObject("Scripting.FileSystemObject")
Function DoStuff(ByVal vsDontModMe, rsImBigDontCopyMe)
End Function
Pre-emptive: Using type prefixes is a good practive to help identifiy what
type a variable is supposed to hold, its worth bearing in mind that since
most variables are variants they can actually hold any type. I've seen
plenty of code using a variable such as lUserID that works fine despite the
variable being drawn from an ASP QueryString and actually be a String not a
Long. Of course that means occasionaly strange things happen so it worth
scrutanising variable assignents to ensure the correct types are being
assigned, e.g. using CLng etc.
Post by FUBARinSFOThe 'Do...Loop Until True' construct I also hadn't seen before. I use
While True ... Wend for blocks of code I want to preserve as a way of
"commenting them out" at runtime. I assumed he was doing that here as
well - except that if this defines a "block", then I assume it is the
"block of code" referred to in the remarks on "OERN" and so makes it
local. The 'Exit Do' confirms this usage, so it's another construct I
can use to help structure this error handling. It's a different way
of structuring the error handler, which in the examples I've seen (and
programmed myself) is placed sfter an Exit Sub statement, with error
handling code at the end. This is another compaction of code style,
where the error handling is embedded in with the code logic -
something I try mightily to avoid, generally by putting the handlers
at the end of the functions, and not using subs at all but rather
functions with return codes.
That is another approach that can create reasonable structure, I've
certainly seen plenty of C code where that was the case. However you loose
the true function semantic such that functions can no longer participate in
expressions as they are designed to. E.g. this:-
Function fnA(x, y)
fnA = Do some stuff with x and y
End Function
Function fnB(x, y)
fnB = Do some other stuff with x and y
End Function
Function fnC(x, y, z)
fnC = fnA(fnB(x, y), z)
End Function
becomes:-
Function fnA(x, y, retVal)
On Error Resume Next
retVal = Do some stuff with x and y
fnA = 0 ' success
End Function
Function fnB(x, y, retVal)
On Error Resume Next
retVal = Do some other stuff with x and y
fnB = 0 ' success
End Function
Function fnC(x, y, z, retVal)
On Error Resume Next
Dim tmp
Dim lErrVal : errVal = fnA(x, y, tmp)
If lErrVal = 0 Then
fnC = fnB(tmp, z, retVal)
End If
End Function
The first approach is sooo much easier to follow but isn't very defensive.
The second approach is a little bit more defensive but what took 1 line of
code now takes 5. The more I think about it the more my head hurts,
VBScript just isn't up to the job if good error handling is required.
Post by FUBARinSFOOverall, 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.
--
Anthony Jones - MVP ASP/ASP.NET