Jump to content

How can you prevent Object errors from killing script?


Recommended Posts

Hey,

I'm delving more and more into using objects in my script. They're great, but I have a problem in that even if you can create the object, a call that fails (and should) kills the script. For example, this:

$oADSystemInfo = ObjCreate ( 'ADSystemInfo' )
$sComputerName = $oADSystemInfo.ComputerName

runs fine on my Work computer that's joined to a Domain, but if I try to run it on my Home machine which only belongs to a Workgroup, the second line fails with

The requested action with this object has failed.

.

Yes, I've looked here and in the Help, and the only reference to error handling points to how to deal with it in a VB script, and even that uses GOTO Label and has no translation into AutoIt.

Any thoughts on how to tame these errors?

Thanks.

Jerry

Link to comment
Share on other sites

Here's a good excerpt that should help from the help file:

COM Error Handling

Using COM without proper error handling can be very tricky. Especially when you are not familiar with the Objects in your script.

An AutoIt script will immediately stop execution when it detects a COM error. This is the default and also the safest setting. In this case you have to take measures in your script to prevent the error from happening.

Only if there is no way to prevent a COM error, you could install an "Error Handler" in which you take action after the error has happened. It is not a solution to make a buggy script work properly. Neither does it catch non-COM related script errors (e.g. declaration and syntax errors).

Error handling is implemented in the same way as a normal COM Event, using ObjEvent() and a user defined COM Event Function. The only difference is the usage of the fixed string "AutoIt.Error" as the name of the object.

An example:

$oMyError = ObjEvent("AutoIt.Error","MyErrFunc") ; Install a custom error handler

; Performing a deliberate failure here (object does not exist)

$oIE = ObjCreate("InternetExplorer.Application")

$oIE.visible = 1

$oIE.bogus

if @error then Msgbox(0,"","the previous line got an error.")

Exit

; This is my custom error handler

Func MyErrFunc()

$HexNumber=hex($oMyError.number,8)

Msgbox(0,"","We intercepted a COM Error !" & @CRLF & _

"Number is: " & $HexNumber & @CRLF & _

"Windescription is: " & $oMyError.windescription )

SetError(1) ; something to check for when this function returns

Endfunc

One thing is special about the Error Event Handler, and that is the Object it returns. This is an AutoIt Error Object that contains some useful properties and methods. It's implementation is partly based on the "Err" Object in VB(script):

Properties of the AutoIt Error Object:

.number The Windows HRESULT value from a COM call

.windescription The FormatWinError() text derived from .number

.source Name of the Object generating the error (contents from ExcepInfo.source)

.description Source Object's description of the error (contents from ExcepInfo.description)

.helpfile Source Object's helpfile for the error (contents from ExcepInfo.helpfile)

.helpcontext Source Object's helpfile context id number (contents from ExcepInfo.helpcontext)

.lastdllerror The number returned from GetLastError()

.scriptline The script line on which the error was generated

Methods of the AutoIt Error Object:

.raise Raises an error event, initiated by the user

.clear Clears the contents of the Error Object (i.e. numbers to 0, strings to "")

A note for UDF writers

You can only have ONE Error Event Handler active per AutoIt script. If you are writing UDF's containing COM functions, you can check if the user has an Error Handler installed as follows:

$sFuncName = ObjEvent("AutoIt.Error")

if $sFuncName <> "" then Msgbox (0,"Test","User has installed Error Handler function: " & $sFuncName)

If no Error Handler was active, you can temporarily install your own during the UDF call.

However, you can never stop an existing Error Handler without releasing the variable it had been assigned to. If the script author had installed a COM Error Handler, it's his responsibility to use a proper function that will also be able to catch COM errors generated by UDF's.

Yuck.. it doesn't format well from the Help file, just search the help file for "COM", and it's the first result, "COM reference", second to last heading on that page. This example handles the errors you're talking about perfectly.

[u]My UDFs[/u]Coroutine Multithreading UDF LibraryStringRegExp GuideRandom EncryptorArrayToDisplayString"The Brain, expecting disaster, fails to find the obvious solution." -- neogia

Link to comment
Share on other sites

Here's a good excerpt that should help from the help file:

Yuck.. it doesn't format well from the Help file, just search the help file for "COM", and it's the first result, "COM reference", second to last heading on that page. This example handles the errors you're talking about perfectly.

neogia,

Thanks. Don't know how I missed that! :) Thanks for not flaming me too!

It's people like you (and there's lots of them) that make this forum great, and make AutoIt a pleasure to work with!

Jerry

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...