Jump to content
Sign in to follow this  
ivan

Com error handler, best proactice

Recommended Posts

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 by ivan

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by ivan

Share this post


Link to post
Share on other sites
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 by ivan

Share this post


Link to post
Share on other sites
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 by ivan

Share this post


Link to post
Share on other sites
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


Free Internet Tools: DebugBar, AutoIt IE Builder, HTTP UDF, MODIV2, IE Developer Toolbar, IEDocMon, Fiddler, HTML Validator, WGet, curl

MSDN docs: InternetExplorer Object, Document Object, Overviews and Tutorials, DHTML Objects, DHTML Events, WinHttpRequest, XmlHttpRequest, Cross-Frame Scripting, Office object model

Automate input type=file (Related)

Alternative to _IECreateEmbedded? better: _IECreatePseudoEmbedded  Better Better?

IE.au3 issues with Vista - Workarounds

SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y Doesn't work needs to be ripped out of the troubleshooting lexicon. It means that what you tried did not produce the results you expected. It begs the questions 1) what did you try?, 2) what did you expect? and 3) what happened instead?

Reproducer: a small (the smallest?) piece of stand-alone code that demonstrates your trouble

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×