On Error Resume Next

[Red-Steel]

Hi,

Is there a way to imitate the "On Error Resume Next" from VB6 to autoit?

So if there is an error it will continue to run and not crash.

Thanks!

[torels]

I think the only way of handling it is using @error macro

[Red-Steel]

yeah but it will still crash if the error is critical

[spudw2k]

yeah but it will still crash if the error is critical

Can you give some example code? If the error is with a COM object you can use this example from the HelpFile.

Global $g_eventerror = 0  ; to be checked to know if com error occurs. Must be reset after handling.

$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 $g_eventerror 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 ) 

   $g_eventerror = 1 ; something to check for when this function returns 
Endfunc

[Richard Robertson]

Critical errors are often due to bad coding, such as not performing an IsArray check before using subscripts. That is, if it wasn't caused by COM, in which case the error handlers work.

[SoftVoile]

is there no way to continue the script run if an error occured?

[torels]

well if the error is very bad...no

$a = _someFunc ;<-- missing () so you have an error
$String = $a & "world" ;$a is nothing... so you will have another error!

Func _SomeFunc()
return "hello "
EndFunc

[Uten]

Hi,

Is there a way to imitate the "On Error Resume Next" from VB6 to autoit?

So if there is an error it will continue to run and not crash.

Thanks!

That is the only, and default, behaviour in AutoIt (at least the last time I checked).

yeah but it will still crash if the error is critical

And so will VB6 if it ain't core VB6 code. That is unhandled errors in API calls could crash your program.

[vicsar]

SoftVoile, Red-Steel,

Check this out, line 26 or so,  (I know, I know, old post, but the problem is still out there for others):

Source:

https://github.com/ellysh/autoit-examples/blob/master/COM/ExcelFileTest.au3

 

expandcollapse popup

#include <Constants.au3>

; Excel file Automation Example
;
; Based on AutoItCOM version 3.1.0
;
; Beta version 06-02-2005

; An Excel file with filename Worksheet.xls must be created in the root directory
; of the C:\ drive in order for this example to work.

Local $FileName = @ScriptDir & "\Worksheet.xls"

If Not FileExists($FileName) Then
    MsgBox($MB_SYSTEMMODAL, "Excel File Test", "Can't run this test, because you didn't create the Excel file " & $FileName)
    Exit
EndIf

Local $oExcelDoc = ObjGet($FileName) ; Get an Excel Object from an existing filename

If IsObj($oExcelDoc) Then

    Local $String = "" ; String for displaying purposes

    ; Some document properties do not return a value, we will ignore those.
    Local $OEvent = ObjEvent("AutoIt.Error", "nothing") ; Equal to VBscript's On Error Resume Next

    For $Property In $oExcelDoc.BuiltinDocumentProperties
        ; $String = $String &  $Property.Name & ":" & $Property.Value & @CRLF
        $String = $String & $Property.Name & ":" & @CRLF
    Next

    MsgBox($MB_SYSTEMMODAL, "Excel File Test", "The document properties of " & $FileName & " are:" & @CRLF & @CRLF & $String)

    $oExcelDoc.Close ; Close the Excel document

Else
    MsgBox($MB_SYSTEMMODAL, "Excel File Test", "Error: Could not open " & $FileName & " as an Excel Object.")
EndIf

 

 

 

[Melba23]

vicsar,

ObjEvent is only a limited solution (mainly used for trapping COM errors)  - if you have a critical error in your plain AutoIt code you will still hard crash:

#AutoIt3Wrapper_Run_AU3Check=n

#include <MsgBoxConstants.au3>

Local $OEvent = ObjEvent("AutoIt.Error", "_Error")

; Create Internet Explorer object
Local $oIE = ObjCreate("InternetExplorer.Application")
; Deliberately cause error by calling non-existing method
$oIE.PlayMeARockAndRollSong()
; Check for errors
If @error Then MsgBox($MB_SYSTEMMODAL, "Error", "COM error")

; Bu tthis is not a COM error
$Vvar = 99
MsgBox($MB_SYSTEMMODAL, "Not COM", $vVar[0])

Func _Error()
    ; Do nothing
EndFunc

M23

[vicsar]

Melba23, 

Yes you are right. It is a limited solution. I guess there is no way around proper error handling (I prefer it myself as well); however, I wanted to show Red-Steel an example I found. I mean, we must understand that sometimes we just want to run and make a simple script due to work deadline and the like.

Red-Steel,

Following is an example of error handling (at least it works for me);

; Activate XOnline App
Opt('wintitlematchmode', 2)
WinActivate("App - Agent")
Sleep(500)

; Triger search
Send("^f")
Sleep(500)
Send("@")
Sleep(500)
Send("{ENTER}")
Sleep(500)

;Find , in Chrome, the higlighted @ sign, orange pixel
$OrangePixel = PixelSearch(390, 170, 1540, 280, 0xff9632)
If $OrangePixel = "AutoIt.Error" Then
    ; Handling the error, if color not found
    ToolTip("", "")
Else
    MouseMove($OrangePixel[0], $OrangePixel[1], 0)
EndIf

;Find , in Chrome, the higlighted @ sign, yellow pixel
$YellowPixel = PixelSearch(390, 170, 1540, 280, 0xffff00)
If $YellowPixel = "AutoIt.Error" Then
    ToolTip("", "")
Else
    MouseMove($YellowPixel[0], $YellowPixel[1], 0)
EndIf
Sleep(1000)

; Copy e-mail from XOnline App. Click at the current mouse position.
MouseClick($MOUSE_CLICK_SECONDARY)
Sleep(500)
Send("e")
Sleep(1000)

 

I trust someone will find it useful at some point.

 

 

[Skysnake]

Is this a good place to ask for common error types, how to solve them and what would be good coding practice to prevent such problems to begin with?

I am very fortunate that I use AutoIt as a hobby, so I am not under the pressures @vicsar alluded too...  I tend to run my code 100s of times before I show it to anyone.  And then still sometimes the unexpected happens... 

My impression is that to "resume after error" one has to be aware of the potential error, and then have code in place to catch the mistake and proceed...

I often preload $var with a default value, then if something goes wrong, the script continues with the pre-defined default.

Edited June 22, 2016 by Skysnake

[Melba23]

Skysnake,

Quote

My impression is that to "resume after error" one has to be aware of the potential error, and then have code in place to catch the mistake and proceed...

Correct.

vicsar,

Your example is complete rubbish - that is NOT the way to handle errors from standard functions such as PixelSearch. What on earth gives you the impression that it could return "AutoIt.Error"? According to the Help file you get:

Return Value

Success: a two-element array of pixel's coordinates. (Array[0] = x, Array[1] = y). 

Failure: sets the @error flag to 1 if the color is not found.

No sign of a literal string such as you propose.....

The way to check for error in this case would be something like this:

$OrangePixel = PixelSearch(390, 170, 1540, 280, 0xff9632)

If Not IsArray($OrangePixel) Then
; Handling the error, if color not found
    ToolTip("", "")
Else
    MouseMove($OrangePixel[0], $OrangePixel[1], 0)
EndIf

or

$OrangePixel = PixelSearch(390, 170, 1540, 280, 0xff9632)

If @error Then
; Handling the error, if color not found
    ToolTip("", "")
Else
    MouseMove($OrangePixel[0], $OrangePixel[1], 0)
EndIf

In either case, if the function does not find the colour, the code does not try to address the return as an array - which would create a hard crash along with the "Subscript used on non-accessible variable" dialog.

M23

[water]

Here are my 2 cents worth:

As described in the help file the function "sets the @error flag to 1 if the color is not found.". It doesn't give any information about the return value in this case.
I remember a discussion with one of the Devs (when there were a "lot" of them). To sum it up: In case of an error the return value is "undefined" when @error is set.
So I would check the value that is set in case of an error. Here it is @error, other functions might set the return value to denote an error.
So I vote for code snippet #2 as posted by Melba above.

[vicsar]

Thanks for your feedback Melba 23. I will PM you.

[JLogan3o13]

@vicsar reporting a moderator? Not the most intelligent thing you can do. And for the record, @Melba23 was a whole lot more gracious in his reference to your post than I would have been. You cannot put forth something that poorly thought out and NOT expect to be called on it.

[Melba23]

vicsar,

I have replied to your PM.

Your code snippet in indeed "complete rubbish" and deserves to be called as such. Sorry you took offence at that remark, but I am afraid that is the truth and I would be remiss if I did not point it out. I carefully pointed out why this was the case and how the code should have been structured - I do not see how this "prevents other from learning", nor how it would "intimidate" them as you suggested in your PM. You can see from JLogan3o13's response above that I am not alone in viewing my response in that light.

If you post any snippets of that quality again you will no doubt get a similar response, from myself or another experienced user. Might I suggest that you post asking whether your approach is correct rather than immediately claiming that you have a solution - that way everyone will be able to learn, which is why we are all here in the first place.

M23