clsVersionControl: Error trapping setting. (We need this to "Break in Class Modules" for this add-in)

[josef-poetzl]

Hi!

Why is "Break in Class Modules" needed? That's the option I never need ;)

Background:
I wanted to run unit tests to test the RunBeforeExport option. Because of "Break in Class Modules" the code stops at the test assert and cannot be processed by the test framework.

I tried "Break On Unhandled Errors" (2) and did not notice any difference.
Am I missing something?

Kind regards,
Josef

[joyfullservice]

Great question! I personally use it for many of the same reasons described here. Because class modules are extensively used in this project, it makes it easier to actually break on the code line that is triggering the error (which is often within a class module), rather than simply highlighting the calling code in the last standard module and requiring me to step through the code line by line to find the actual breaking point within the class.

For your unit testing framework, you might consider setting the VBA option yourself before executing the test suite, just to ensure consistent behavior, regardless of which setting the user is currently using. You can see how I do this in the add-in here:

msaccess-vcs-addin/Version Control.accda.src/modules/clsVersionControl.cls

Line 491 in 8c9f86d

strValue = Application.GetOption("Error Trapping")

[josef-poetzl]

Hi!

The behavior only occurs when I want to test the VCS add-in (clsVersionControlRunBeforeExportTests).
First, my test framework sets Error Trapping = 2, then the test is started with the VCS add-in and the VCS sets Error Trapping to 1 during the test run.
This is not a problem, as I can switch back to 2 in the test procedure before the assert if necessary. However, if there is no particular reason for 1, I leave my fork at 2.
I was just curious as I only use 0 and 2 myself. :)

[joyfullservice]

Some of that probably comes down to the personal preferences and debugging approach of each developer. 😄 If the testing framework is expecting or needing a specific level for the desired functionality, I would suggest caching the current value, setting the needed value (in this case 2), then restoring the user's preference. That way the test can run consistently, regardless of what value the developer was using.

Just a tip on implementing this, I have found that it is usually much more performant to read the current value and only change if needed, rather than always setting the value. (Reads on property access tend to be much faster than writes.) Of course there is a balance between performance, readability, and actual need.

[josef-poetzl]

I would suggest caching the current value, setting the needed value (in this case 2), then restoring the user's preference.

I use a helper class ErrorTrappingObserver for this in VBA, so the code looks like this:

With New ErrorTrappingObserver
      .ErrorTrapping = BreakOnUnhandledErrors
     ' start anything here
End With

You could also think of something like this in the VCS add-in:

    strValue = Application.GetOption("Error Trapping")
    If strValue < "1" Then  ' < 1  vs <> 1
        PreserveSetting "Error Trapping", strValue
        Application.SetOption "Error Trapping", 1
    End If