Error Handling - call Err.Raise from another module

I have the class module and several code modules in ActiveX-dll project. All of modules has common this-module-level procedures as local err handlers. And all of this handlers in different modules are very similar, so I want to move them in special module, containing all err-related procedures.

But the only question is there for me:

• Is it correct to raise user-defined err from another module?

This is especially important in case of the class, that will be many times instanced in user app and I'm afraid this a little bit.

Say, err conditions are become in My_Class.BadProcedure() and it calls user-err-maintance procedure in Module_Err.ErrRaise() that (after many err attributes assignments) calls finally Err.Raise, that must return us upside on the calls stack to My_Class.BadProcedure() error handler (or err handler on up level).
.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Tom!
No answer. (C)

Addendum:

Ok, let's simplify the task.

Let's forget about the class. It's realy difficult - every time create object by pointer and then destroy it. Let him to use their own copypaste of common error handling code.

But what about remaining task - to do it between code modules only?
It is possible, yeh, but is it safe amd correct?

Code:

---


' Module3
Public Sub sp_TestErr_Raise(pNmb&, pSrc$, pDsc$)
    Debug.Print "Module3: Beg_sb_TestErr_Raise"
    Call Err.Raise(pNmb + vbObjectError, pSrc, pDsc)
   
    Debug.Print "Module3: End_sb_TestErr_Raise - Never will be printed"
    Stop    ' We can't be here
End Sub


' Module4
Private Sub sb_TestErr()
On Error GoTo ErH
       
    Debug.Print "Module4: Beg_sb_TestErr"
    Call Module3.sp_TestErr_Raise(12345, "Beg_sb_TestErr", "12345")
   
    Debug.Print "Module4: Mid_sb_TestErr"
    Call Module3.sp_TestErr_Raise(54321, "Mid_sb_TestErr", "54321")
       
    Debug.Print "Module4: End_sb_TestErr"

ErX:
    Stop
    Exit Sub
ErH:
    Debug.Print "Module4: " & _
                (Err.Number - vbObjectError) & " - " & _
                Err.Description & " - " & _
                Err.Source & vbLf
    Stop
    Resume Next
    Resume
End Sub

'
' Module4: Beg_sb_TestErr
' Module3: Beg_sb_TestErr_Raise
' Module4: 12345 - 12345 - Beg_sb_TestErr
'
' Module4: Mid_sb_TestErr
' Module3: Beg_sb_TestErr_Raise
' Module4: 54321 - 54321 - Mid_sb_TestErr
'
' Module4: End_sb_TestErr
'

---

.

Up. Addendum.
.

There will not be any difference if the error handling code is in a separate standard module in the *same* project. You can include this standard .bas module is all your projects as a separate standard module with no problems as well.

But you have to realize that built-in Err class has separate instances *per project*, i.e. setting Err.Number = 123 in Project1.mdErrorHandler will not show up in Err.Number when accessed from Project2.mdErrorHandler, just FYI.

Err.Raise is another beer altogether. . .

cheers,
</wqw>

Quote:

---

Originally Posted by wqweto

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

wqweto, Elroy,
thank you very much for detailed and useful explanation.

It help me very well, like the previous discussions too. Now the structure of my project will be much simpler, and the logic of it work and transparency will be significantly improved by removing redundant, duplicate code.

Regarding to global nature of Err object and its short life-cycle (which was repeatedly emphasized by you), I do the following:

immediately after error (any - my or MS) raised, I clone Err-object into local UDT, declared in procedure, which contains error handler. This UDT has all fields, corresponding to Err-object, and several additional fields. And further I manipulate with this UDT only, forgetting off about original Err object. So, I can manipulate with it not only inside this procedure, but pass it further for maintence to other procedures and between code modules too.

Re inter-project's error exchange (thank you once more), so I choice the way (it was discussed with you earlier too) to return error flag instead of value, expected by user, and provide access of user app to last error info. Moreover, not only to last, but to the stack of errors if there were several.

I want to stress once again that this progress has been achieved in many due to your support.

The most offensive :) that all this is necessary for 99% only for me - no one error has arisen, except my own logic errors and bugs in code :) - not in IDE, not in both compiled projects (ActiveX dll and user app).
.