Error Handling - call Err.Raise from another module

[Elroy]

Err.Raise is another beer altogether. . .

Say wqweto, I'm not sure why you say that.

Also Asbo, wqweto has you on the right track. There is only one error handler per project. Now, if you want to pass errors from an ActiveX (in process) component back to the main program, that is another animal. However, if we keep our thinking to a single project, there's just one error handler ... no nesting of any kind involved.

Back before VB6, Microsoft did play around with getting some "Local" error handling going, but they could never make it work correctly, so they backed off of it.

So, there's only one error handler (per project), and there's only one Err.Number value. Now, if you look at the properties of the Err object, and you use Err.Raise, you can store additional information in the Err object which is often useful. However again, there's only one Err object per project.

This also has a couple of "got'chas" in it you need to be aware of. For instance, if you use On Error Resume Next to plow through some code that may generate errors (say, looking for the TabIndex of all controls on a form, when some may not have the property), you may wind up leaving a value in the Err.Number property. Unless you specifically clear the Err object after using On Error Resume Next, you're never sure what'll be in there.

The MSDN actually explains all of this fairly nicely.

---

And one last thought about all of this. This is just a personal opinion, and everyone will have somewhat different opinions about this, but I virtually never code with global error trapping turned on. We've had this discussion many times, but I take a "proactive programming" approach (rather than being reactive to errors). In other words, I do my best to think of every possible error producing scenario, and cover those bases, thereby forgetting about any error trapping.

Sure, my main application is huge enough that users do occasionally find ways to twist it up so that an error is produced. When that happens, I use the information and build in a new validity check with associated warning message that they've tried to do something that's not allowed. (And, God forbid, I do occasionally program in the occasional bug. )

Personally, I think error trapping is just clutter in the code, and we can go WAY WAY overboard with the stuff. Again, just my two-cents.

And, let me finish by saying that I'm not opposed to error trapping for various purposes. In fact, I outlined one above ... looking for TabIndex values in all my controls. And I might use error trapping to "test" to see if the user is doing something wrong. But I never just put generic error trapping in to try and catch unknown/unforeseeable errors. I'd much rather learn the language, and understand what all the reasonably foreseeable errors are. (I'll exclude failing hardware and networking rights issues from that list.)

Best Of Luck,
Elroy