Com error handler, best proactice

[ivan]

In writing scripts that use several libraries that create COM objects, say using IE, Word and Excel UDFs, or when creating custom objects with AutoitObject, we would typically write a COM error handler in the main script that typically looks like this:

; register the error handler
$oMyError = ObjEvent("AutoIt.Error","MyErrFunc")

; COM error handler
Func MyErrFunc()
  $HexNumber=hex($oMyError.number,8)
  Code ...
Endfunc

MyErrFunc is triggered by the error event, regardless of the object. At least two procedures come to mind for handling the errors, one within the handler itself or checking $oMyError after calling a property or executing a method (and after MyErrFunc has been executed). In the first case, and please correct me if I'm wrong, but we would have no reference to the object that failed, and the latter case would make long scripts.

Is there a third possibility? Am I missing something?

I would much apprecitate if someone could shed some light into this topic.

IVAN

Edited May 6, 2010 by ivan

[zorphnog]

You could make a global object, say $g_oCurrent, and set it to the object before you perform any action on the object. Then you could reference it in your error handler.

[ivan]

Sounds safe and definitely shorter than checking $oMyError after each property or method is called.

I rushed, so edited in place.

; register the error handler
$oMyError = ObjEvent("AutoIt.Error","MyErrFunc")

Global $g_oCurrent, $obj1, $obj2
.....
$g_oCurrent = $obj1
... all actions with $obj1 until changing current obj
$g_oCurrent = $obj2
... all actions with $obj2 until changing current obj

; COM error handler
Func MyErrFunc()
  $HexNumber=hex($oMyError.number,8)
  Code ...
  ;;; $g_oCurrent now holds the reference to the current object
Endfunc

Cheers. I'm still wondering if there are other practices one may use...

Edited May 6, 2010 by ivan

[ivan]

I am examining how Dale wrote the error handler for the IE library. Within the body of _IEAttach (and other functions) he registers an internal error handler, __IEInternalErrorHandlerRegister(). He also provides a de-register function, which is quite interesting.

I take it MyErrFunc() will actually be overwriten by the IE error handler. Therefore, one would have to re-register the MyErrFunc() error handler once we're done with IE.

Edited May 6, 2010 by ivan

[ivan]

I see Dale has two layers for handling errors, the internal __IEInternalErrorHandlerRegister() and the user handler which is registered by _IEErrorHandlerRegister ( ), if the main script calls this function.

I'm still trying to understand the workings of this, but it would make much sense to write (and register) handlers for each com object. Registration and de-registration of handlers would then be required once the current object is changed. This, or writing a larger com error handler for all objects created within the script, as suggested by zorphnog's post above.

This should be safe in principle, and I will personally keep it as a general procedure, unless, that is, if someone has any better ideas.

@Dale: I'm only tring to understand the principles behind your error handling procedures, which I must say, are quite illustrating.

IVAN

Edited May 6, 2010 by ivan

[DaleHohm]

The error com error handler logic in IE.au3 plays well with a com error handler you may define in your script (so long as you use the global variable documented in the _IEErrorHandlerRegister() docs), but it will not play well with com error handlers used in other UDFs. This would take a coordinated effort accross all of the UDFs. It is a tough problem since only one error handler can be defined and the only hook to it is via an arbitrary variable name.

Valik has a trac ticket logged to evaluate and revamp the entire design, but it would be a big effort.

Dale

[ivan]

The error com error handler logic in IE.au3 plays well with a com error handler you may define in your script (so long as you use the global variable documented in the _IEErrorHandlerRegister() docs), but it will not play well with com error handlers used in other UDFs. This would take a coordinated effort accross all of the UDFs. It is a tough problem since only one error handler can be defined and the only hook to it is via an arbitrary variable name.

Valik has a trac ticket logged to evaluate and revamp the entire design, but it would be a big effort.

Dale

@Dale:

First, thank you for taking interest in the subject and for sharing the info.

You're definitely well informed. This sounds like mammoth task. I suppose until Valik re-builds error handler structure accorss UDFs we're pretty much left to our own devices.

Your insight into this is of great help. I thought a solution could be elevating the error handling globals to a common #include-once file where these globals are declared, therefore allowing both IE and my script (and other UDFs) to share the same variables.

Using this procedure, I should also try to edit other UDFs to share these values, maybe adjusting for de-registration and re-registration of handlers (functions). Here each type of object created would have its own error handling function.

Does this make any sense? Am I running around in circles?

Regards,

IVAN