dcsimg
Results 1 to 5 of 5

Thread: Error Handling - call Err.Raise from another module

  1. #1

    Thread Starter
    Member
    Join Date
    Mar 2018
    Posts
    35

    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
    '
    .
    Last edited by asbo; Aug 1st, 2018 at 09:38 AM. Reason: Soften task conditions

  2. #2

    Thread Starter
    Member
    Join Date
    Mar 2018
    Posts
    35

    Re: Error Handling - call Err.Raise from another module

    Up. Addendum.
    .

  3. #3
    Frenzied Member wqweto's Avatar
    Join Date
    May 2011
    Posts
    1,975

    Re: Error Handling - call Err.Raise from another module

    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>

  4. #4
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,222

    Re: Error Handling - call Err.Raise from another module

    Quote Originally Posted by wqweto View Post
    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
    Last edited by Elroy; Aug 1st, 2018 at 10:55 AM.
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  5. #5

    Thread Starter
    Member
    Join Date
    Mar 2018
    Posts
    35

    Re: Error Handling - call Err.Raise from another module

    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).
    .

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width