Raise error in caller

[Monkey36]

I'm trying to get to grips with raising errors appropriately in VB6. What I've got is a class method that will only accept parameters of a certain form

eg.

Form:
Sub Form1_Load
  Set Class1 = New CTestClass
  Class1.CallMethod 1, 2
End Sub

Class:
Public Sub CallMethod(Arg1, Arg2)
  If Not (ValidArgs(Arg1, Arg2)) Then
   Err.Raise ..
  Exit Sub
  ..
End Sub

The working aren't important, but you get the idea. Now, what I want to happen is when the error is raised, for the "Class1.CallMethod 1,2" line to be highlighted, not the "Err.Raise .." line - I want the error to be passed up to the caller, rather than raised in the class.

Can this be done?
Am I missing something obvious?

If anyone could guide me along the right route it would be greatly appreciated!

Cheers,
Dan.

 

[jebenson]

You could just make CallMethod a function that returns true or false, just like the ValidArgs function that gets called in CallMethod.




I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

 

[strongm]

VB does bubble errors back up the call stack to find an error handler. If it gets to the top, it let's the default VB handler deal with the error. However, the behaviour can be modified through some global VB settings. I would suspect that you have either got got 'Break on all errors' or 'break in class module' set.

Have a look at Tools/Options/General/Error Trapping

or

Right-click in code pane, select the Toggle option, and then select the appropriate error handling

 

[Monkey36]

Thanks for the input, however I've got issues with both points :

Firstly, I'd like to be able to do a similar thing for properties as well as classes, so I can't really use the return value

Public Property Get Value(intIndex as Integer) as Integer
 If Not IndexValid(intIndex) Then
  Err.Raise ..
  Exit Sub
 End If

 ..
 Rest-of-property-retrieving-code
End Sub

And this kinda leads on to the second point. I liked that fact that "Break on unhandled errors" showed the error in the function calling the class method when I raised an error. However is it possible to distinguish between errors raised internally and errors raised intentionally? In other words, say I'm debugging my class code and I make a mistake in the "Rest-of-property-retrieving-code" part above which causes VB to throw an error. Is it possible to highlight the line I made the mistake in in the class, but if the Err.Raise line raises an error that that error appear in the calling function?

I'm guessing that they will be handled identically, and that it's not possible for this scenario to work, but I can always be optimistic!

Any ideas?
Thanks again for the suggestions.

 

[strongm]

It's not possible for that scenario to work ...

 

[Monkey36]

Hmm.. I nearly got excited because it seems that in VBA it might be possible to do what I wanted by programatically changing the Error Handling state (I could wrap the Err.Raise in a function that would ensure that Error Handling was set to "Break on unhandled errors" temporarily, and set it back afterwards) by using

  intPrevErrHand = GetOption("Error Trapping")
  SetOption "Error Trapping", intNewErrHand

Now I've not had any luck finding an equivalent in VB6, but as a bit of a last ditch attempt I thought I'd check whether anyone else knows of something that would work like this.

I understand that VBA will be different from VB6 in some areas, seeing as it is not designed to be compiled, but functionality like this would be nice for debugging in VB6.

Any takers?

 

[strongm]

I'll rephrase: It's not possible for that scenario to work in VB6...

I'd also point out that the SetOption technique you have discovered is not a VBA technique; SetOption belongs to the Access Application object, not to VBA (so the trick only works in Access, and not in other VBA hosts such as Excel, Word or Powerpoint)

 

[Monkey36]

Oh, well. Looks like I'm not going to get what I want then *sulks*

Thanks a lot for your input anyway!
Take it easy.

 

[BobRodes]

,is it possible to distinguish between errors raised internally and errors raised intentionally?

Yes, but not using the means you describe. If you want to find out where an error was raised, you can use the Source property of the Error object. The source property will be the name of the component that raised the error if it's an internal error, and will be whatever you set it to when you raise the error yourself. For example, if you do, say, a division by zero in your class module, err.source will be your component name. However, if you have an ADO connection string with a non-existent server in your class, err.source will be "OLE DB Provider for SQL Server".

HTH

Bob