1) Recognize that booleans can be assigned the result of a test and don’t require an If test with a corresponding assignment of a true/false value.

2) Use the boolean approach but skip the If Not Oops tests

3) Use a GoTo as an error handler. That’s a limited application of the development philosophy that any forward-moving GoTo is OK. [GoTos become a nightmare when people jump back-and-forth with them.]

4) And, of course, one can enhance the above by using an Enum to better explain the error.

For 95% of the code I write that is probably true — not to mention that during development it is often a must that no error handler be enabled except for specific *anticipated* errors.

But, it sometimes makes for extremely convoluted implementation of a fairly straightforward algorithm. One instance where I use ‘on error resume next’ extensively is in the context of an Excel chart. At times detecting whether a certain property or method applies to the chart at hand is more work (requiring more cumbersome code that is harder to read, understand, and maintain) than simply making the change and falling through in the event of an error. Not only does this make the code more streamlined but I don’t have to worry about falling over when (if?) Microsoft introduces new chart types.

And, there are a number of such instances where handling errors is easier than detecting the possibility of an error. Not only with Excel but with other applications and in building web based solutions using, say, asp and javascript.

I hold that the VBA On Error statement should not appear in application code, since anything you can program for after the event you can program for before the event.
I do allow On Error statements to appear in library routines written by the senior developer (me!) to allow the application developer (me again!) to avoid On Error statements in applications.
Many examples abound:
(1) a procedure to determine the number of dimensions of an array (APL: “rank”)
(2) a procedure to determine if a file exists (originally the good old FileLen statement test)
(3) borderline cases such as this one:
Public Function blnProcedureExistsInModule(strProcedureName As String, strModuleName As String, doc As Document) As Boolean
On Error Resume Next
If blnModuleExistsInDocument(doc, strModuleName) = True Then
blnProcedureExistsInModule = doc.VBProject.VBComponents(strModuleName) _
.CodeModule.ProcStartLine(strProcedureName, vbext_pk_Proc) 0
End If
End Function

Back on topic: That said, I suspect that sometimes it just makes more sense to have code in-line, that is, it can, at times, make the application code more comprehensible to future readers.

We now return you to our regular programming …

Interpretation and Compilation are two sides of the generic “translation”, and any fear of future methods of translation are valid fears (not to say that they will come true, just that they are arguable).

I suspect the easiest way for VBAers to see this is to take Tushar’s approach and write a small procedure to handle these awkward tests. I do that often. When I take a chained AND condition and embed it into a VBA procedure, I become the translator, it is MY decision as to which condition is evaluated first, and which condition is evaluated conditionally on the first.

Thus you and I could translate the same condition in two different ways.

That said, is all the more reason for using Libraries of utility code rather than duplicating code.

As an aside, while the Select Case True approach is very appealing, I’ve learned the hard way (harking back to my FORTRAN and assembler days) to not rely on the sequence in which a particular compiler generates code. In VBA it seems like it has been sequential (top to bottom, left to right) for as long as I remember but who knows? If Microsoft ever provides a graceful transition from VBA to the .Net world, the compiler rules may change.

In any case, here’s how I’ve handled these kinds of scenarios. Reverse the tests to get a much simpler structure that also allows one to provide more informative error messages. This technique to removing “bushy trees” is one of the few things I still remember from ‘The Elements of Programming Style’ by Kernighan and Plauger (http://www.amazon.com/Elements-Programming-Style-Brian-Kernighan/dp/0070342075/ref=sr_1_2?ie=UTF8&s=books&qid=1280125164&sr=8-2), which IMO is a must read for anyone who aspires to anything more than just using the macro recorder.

Alternatively, simulate Try…Catch…Finally though I don’t like it all that much because it also traps errors in the 1st MsgBox and the assignment.

C-like/spawned languages have && [and] and || [or] operators which perform short-circuit Boolean evaluation. That is, if the left side of && (||) is false (true), then the result of the && (||) expression must be false (true), so no need to evaluate the right side. These are (in C semantics) strictly Boolean operations with both sides converted to 1/TRUE if nonzero or left as 0/FALSE before the comparisons are performed.

OTOH, VBA’s And and Or (and Xor, etc) operators are BITWISE operators rather than Boolean operators. They’re performing operations on ALL bits from BOTH SIDES of the operators, so both sides must be evaluated. Royal PITA.

You could always use boolean state variables to approximate short-circuit boolean evaluation.