Discussion on:

10 ways to screw up your VBA code

... any error message provided by the developer should include - in the window title or in the error message - complete identification of the error provider.

I don't know anyone who runs only one application at a time, and there's always the OS, services, et.al. I cannot count the number of times a message box has popped up telling there has been an error - but it doesn't tell me what application is providing the error message!

Yeah, as a developer I _know_ where the error resides. But as a user, I have no idea what owns the error.

Gee, it takes all of three (3) seconds to identify the message window ... and I'd really like to know whether the OS is complaining about your code, or your code is complaining about my usage!

Considering that the GoTo is the most basic error handling.

/Sarcasm

Usually when I write code, I wrap all functions in
On Error GoTo Oops
'inner code, may contain more error handling for specific errors
Exit Sub
Oops:
call msgbox(err.description) 'This is example only, real error message is better
'do cleanup
End Sub


This way I'll never get an end/debug error.

it's not the only way to change non-exceptional program flow though.

I really missed exceptions when I got lumbered with VB6.

The worst habit of all has to be just sticking on error resume next in and crossing your fingers though.

My rational is opposite to yours, I want a full app stop for any condition I haven't dealt with, even go right back to the beginning and start again can be an iffy proposition in a complex program.

A nice something has gone wring, may be write to a log, and then halt as an outer exception handler is ok. But if things went that bad it got to there, I don't want it to do anthing else, because it's likely to make things worse.

I do not know what you write, but what I write is 1 or 2 modules among 1000's, my code has no right to make a user lose a days worth of work cause I wrote a bad piece of code or forgot to handle an exception. Worst case, what my code did is now fubar'd, but not the rest of the system.

so then it can make a decision on what the failure in 'your' code means to it..

No, SinisterSlay, my code's not crap -- sorry. I don't use GoTo. I suppose I would if I needed to, but I don't. I include appropriate error handling too. I suppose I should've been more specific -- using GoTo instead of function calls to direct the flow of traffic. Of course, you need GoTo as part of an On Error statement, but then... I would call that an On Error statement, not a GoTo.

nt

Seeing as how it's automatically put in the code to handle Errors when you select "Event Procedure" in the Event tab of a field's properties.

Edit: Oops my mistake. It doesn't when you do the above (just did it myself lol) but it does automatically put it in when you create a button with a Click Event) /Edit

I leave this bit of code in because it does in fact, display a popup with the Error Description when something doesn't go right in your procedure.

I do use "GoTo" in Loops to avoid working with [many levels of] indented branches of especially If's, like in:

For Each Item in Collection
If Not Item.Condition Then GoTo NextItem


NextItem:
Next Item

Rather write a routine to filter the records I want to process than pass that to one to process them.

I also don't like 1 line If's cause they break the block flow of VBA. IIF's I have no trouble with however.

I think all professional VBA programmers would agree that this is the one (and only) exception for the use of "goto".

Just thinking about it makes my head hurt.

Usually call the variable or constant it's stored in password as well.
Fortunately their code is usually so bad, no one wants to crack it anyway.

I know people do stupid things, but i just can't grok why anyone would bother doing that.

anything.
VBA has it's own issues of course, but there are gotchas in any language. Getting the fundmamentals of making your code comprehensible always helps.

That can go wrong in many ways, and makes your code harder to read.

You are just about guaranteed that whomever (even yourself) are going to want to change and/or expand what it does at first. If you write it rigidly and sloppy, it will me a whole rewrite to change it. Write it with expandability and flexibility in mind. It will save you time and headache in the future.

I wrote an article about "next iteration" without using the GoTo statement:
http://www.experts-exchange.com/A_2755.html

I don't need an expert sex change.

I know I'm in the minority, but I've never been a big fan of adding a qualifier to your variable to identify its type, especially the primitives. I've seen too much code where it became necessary sometime in the life of the app to change the type (int to float, short to long, etc), which either left you with a misleading name, or required an exhaustive effort to find all the instances, update their names, and test accordingly. I'm all for standards, but this convention has rubbed me the wrong way my entire career.