Correctly handling error in instantiating class / stopping main program execution

[mdlueck]

Why can’t you answer this question directly; did you test the code I posted in post #14?

Yes I did test that scenario posted in #14.

And I replied with my findings of why it was not a suitable solution to the problem.

 

[ChrisO]

In which post did you state that, what post number?

Chris.

 

[mdlueck]

Directly after it, #15.

Will there be any further questions in the cross examination?

 

[ChrisO]

Yes…

Where exactly in post #15 does it say you tested the code I posted in post #14?

Chris.

 

[mdlueck]

Where exactly in post #15 does it say you tested the code I posted in post #14?

The part that I KEEP quoting back to you and you state that you need a post # in order to successfully submit the evidence:

Production use of my classes uses the Clear() method to reset the class to all defaults. So code itself calling Clear() would have its own error handling present, creating an instance of the object / Clear() getting in trouble, THAT I need to bomb out of the application for.

Plainly:
1) Clear() needs to handle its own errors
2) Only Class_Initialize() should raise to the caller

How do I know that? I tested that scenario.

 

[ChrisO]

>>How do I know that? I tested that scenario.<<

That does not answer the question, the question was; did you test the code I posted in post #14?

Chris.

 

[mdlueck]

>>How do I know that? I tested that scenario.<<

That does not answer the question, the question was; did you test the code I posted in post #14?

How does I TESTED THAT SCENARIO not answer if I TESTED THAT SCENARIO or not!?!!?

In the Clear() event error handler you have a Err.Raise. I tested that scenario and it failed due to the fact that Clear() is a class method code using the class calls and is not in need of having errors Raised to it.

The only places in class code it looks I presently need to raise errors was stated in #19:

Thus, I let Clear() take care of its own errors and only Class_Initialize() raises errors.

For now the standard I am proposing is that all methods take care of their own errors. Only in two cases do I Err.Raise

1) In code that I do not intend to have to check the return code of each call to a Class... such as my TxtFile class... I want to be able to put a lot of calls to that class in succession without having to code error checking on a per-call basis, just Err.Raise and let the Err handler of that code escalate the Err. No matter was it the first or N'th call to the TxtFile class, the general error handler is good enough protection... I do not need customized error handling beyond what is already provided. (Which that was the thread I referenced in my OP)

2) Now in Class_Initialize() it appears to be helpful to capture failed initialization of class instances.

I am trying to handle errors locally and NOT make a mess of this class architecture by Raising errors all throughout it.

 

[ChrisO]

>>How does I TESTED THAT SCENARIO not answer if I TESTED THAT SCENARIO or not!?!!?<<

Kind of obvious really; you testing THAT SCENARIO might only test THAT SCENARIO which you wrote.

Again; did you test the code I posted in post #14?

Chris.

 

[RainLover]

Private Sub Class_Initialize()
 
   Me.Clear
 
End Sub
 
 
Public Sub Clear()
 
    On Error GoTo Err_Clear
 
    Dim intA As Integer
 
    intA = 1 + "A"
 
Exit_Clear:
  Exit Sub
 
Err_Clear:
  MsgBox "Class: clsObjProjectsTbl, Subroutine: Clear()"
 
  Err.Raise vbObjectError + 1, "Class: clsObjProjectsTbl, Subroutine: Class_Initialize()", "Error: Failed to instantiate class instance."
 
  Resume Exit_Clear
 
End Sub

I think what Chris is asking is did you test the actual code as it appears above, or did you simply take a part of it and just test that part.

I would also like to make the comment that mdlueck is making this difficult to follow as he tends to say more than what is required. Simple English would help.

 

[gemma-the-husky]

just thinking again

if the class initialise fails in some way, can you not just set some property in the class as an indicator.

maybe then you could have another method to try and fix the (reported) error, or just report the failure as appropriate when the class is actually used.

of course it depends exactly how critical an error in the class actually is.

 

[mdlueck]

Private Sub Class_Initialize()
 
   Me.Clear
 
End Sub
 
 
Public Sub Clear()
[B]  [COLOR=Red]On Error GoTo Err_Clear[/COLOR][/B]
  
  Dim intA As Integer
 
  intA = 1 + "A"
 
Exit_Clear:
   Exit Sub
 
Err_Clear:
   MsgBox "Class: clsObjProjectsTbl, Subroutine: Clear()"
   [B][COLOR=Red]Err.Raise vbObjectError + 1, "Class: clsObjProjectsTbl, Subroutine: Class_Initialize()", "Error: Failed to instantiate class instance."[/COLOR][/B]
   Resume Exit_Clear
 
End Sub

I think what Chris is asking is did you test the actual code as it appears above, or did you simply take a part of it and just test that part.

Yes I tried exactly that.

1) Turning on error trapping in a method
2) Encountering an exception
3) Then notifying the caller by Err.Raise

The second the code passes the Err.Raise all of the Err data is lost and replaced with "Automation Error".

In #13 I happened across a solution to that problem... I found I must turn off error handling, then raise a brand new error if I do not want "Automation Error" to be the error the application reports.

I found this page encouraging before I discovered what I posted in #13:

"Automation error, and Err.Raise"
http://www.internetcomputerforum.com/visual-basic-forum/252846-automation-error-err-raise.html

In it I will quote:

I did a Google search in the *.vb newsgroups for anything relating to "Automation error" and "Err.Raise". There were lots! Unfortunately, there was a lot of guessing and folklore amongst the replies. Worse still, there was some absolute rubbish written about error handlers not being able to raise further errors, or handle errors incurred during their own cleanup -- but that's off-topic.

As encouraging as it was to read that... it still did not articulate that trying to propagate an error to be handled by the caller will result in the error information being overwritten by "Automation Error" when program control is returned to the caller.

1) One MUST handle the error locally.
2) If it is desirable to raise an error to notify the caller, it seems IMPARATIVE to TURN OFF error handling, then raise a brand new Error, ELSE what the caller receives is "Automation Error" garbage.

It does not appear possible to enable exception trapping in a class method and expect the calling program to provide the error handling with error exception delivery via Err.Raise... the SECOND the code passes err.Raise, all of the debug information contained in the Err object is destroyed and replaced with "Automation Error".

 

[mdlueck]

if the class initialise fails in some way, can you not just set some property in the class as an indicator.

Yes, good reminder. That would work, so long as all code using the class is always coded to verify health of objects created.

I was seeking a way to not have to code a check and to still receive accurate error information... aka not "Automation Error", but rather my custom error text I thought I had sent when I did the Err.Raise.

 

[RainLover]

Michael

I think that that is the type of answer ChrisO was wanting verified.

So lets see what ChrisO has to say now that that point has beed cleared up.

I can't see why you did not reply like this earlier.

 

[mdlueck]

I think that that is the type of answer ChrisO was wanting verified.

So lets see what ChrisO has to say now that that point has been cleared up.

I can't see why you did not reply like this earlier.

It seemed to me ChrisO wanted both brief posts but then again with lots of details.

If he was unwilling to understand a brief "Yes I tested / verified" but now would be willing to accept my verbose answer... Like you said ""

 

[mdlueck]

All right, testing further this morning...

It appears preferable that I move the error handling to the Clear() method and put back Class_Initialize() to its simplistic implementation.

This way I may propagate Clear() errors to the code calling Clear() and also handle failed instantiation of objects in the first place.

Still, the critical point is the

On Error GoTo 0

LOC which is responsible for preventing an "Automation Error" aka Double Trap.

Private Sub Class_Initialize()

  Me.Clear

End Sub

'This is a generic API that clears all of the field attributes
Public Sub Clear()
On Error GoTo Err_Clear

  Me.id = 0
  Me.authid = 0
  Me.authusername = vbNullString
  Me.logtimestamp = vbNullString
  Me.title = vbNullString
  Me.budget = 0
  Me.rptactiveflg = False
  Me.rpttitle = vbNullString

  strFETempTableName = "tmptblqry_projects"

Exit_Clear:
  Exit Sub

Err_Clear:
  Call errorhandler_MsgBox("Class: clsObjProjectsTbl, Subroutine: Clear()")
  'Disable further error handling. Since the code was already handling an error, if we raised the error without first
  'turning it off, that would result in an "Automation Error" aka Double Trap
  On Error GoTo 0
  'Raise the error to the caller program
  Err.Raise Number:=vbObjectError + 1, _
            Source:="Class: clsObjProjectsTbl, Subroutine: Clear()", _
            Description:="Failed to Clear() class instance"
  Resume Exit_Clear

End Sub

So in application code which calls Clear() to reset the class instance, it may handle a Clear() failure as it so chooses.

In the case of Form_main / Form_Load() encountering such an error, I choose to bomb out of the entire application. Again, it is up to the implementer of the object how seriously to take the Err.Raise received.

At least now I gained the choice of how to handle the error, and to not have to call a special "HealthCheck" class method.

 

[ChrisO]

Michael.

The code you posted in post #31 does not raise an "Automation Error" for me.

Please see the Access 2003 attachment.

Chris.

 

[mdlueck]

The code you posted in post #31 does not raise an "Automation Error" for me.

Please see the Access 2003 attachment.

I no longer have A2003 readily available to me. Tomorrow I will review your sample with A2007.

 

[RainLover]

ChrisO

I tested on Windows 7 64 Bit Access 2003 and
Windows XP Access 2007

I get two error messages on each.

Hope this helps.

 

[mdlueck]

The code you posted in post #31 does not raise an "Automation Error" for me.

On A2007, in the Class I get the correct error.

As soon as the code passes the Err.Raise LOC, the global Watch on the Err object changes to: "Error: Failed to instantiate class instance."

That is certainly more meaningful than "Automation Error".

The point remains valid that in order to receive the exact "Type mismatch" message, I must do local error trapping. Even in your example, the details are changed when the code passes Err.Raise.

I upgraded your database to an A2007 file format, the "Error: Failed to instantiate class instance." persists. So either merely upgrading the DB file format did not shake loose the more intuitive error message, or perhaps there is some reason that my code morphs the error into "Automation Error".

 

[ChrisO]

Michael.

>>The point remains valid that in order to receive the exact "Type mismatch" message, I must do local error trapping. Even in your example, the details are changed when the code passes Err.Raise.<<

Of course the error message changes, your code changes it.

What message do you want to return to the Load event of the Form?
“Error: Failed to instantiate class instance.”
Or
The description of the original error.

Attached is the method to return the original error, please run it from the Form provided for testing.

Chris.