The error handling is automatic, meaning if anything goes wrong, any internal operation returns an error code the script aborts and the job fails. The error message is then written to the job log. Normally you don't need to test for errors as this is already done for you. If you want to change the default behavior you can use "On Error" statements to control script flow and create own error handlers. The syntax is different for JAL and VBS but the idea is the same, OnErrorIgnore or On Error GoTo 0 cause the script to continue, OnErrorGoto [LABEL] and similar cause the control after an error to be transferred to the specified label, and so on. Multiple error handling blocks can be used in a single script. In JAL you can obtain last error message using GetLastError in VBS you can use the error object. You can then test the returned data and respond differently. Other a better way to handle problems like file doesn't exit is locked is to test for condition before attempting to access this file. Because in many cases in both JAL and VBS you will get a "common" error that file "cannot be copied" for instance and you would know is that because the file is not there or just locked. : Hi, : When executing a JAL script what precisely constitutes an error condition and
: what are the best means to test for errors ? : For example - is a syntax error on a JAL statement in the script considered
: an error status when the script runs ? and if a parameter to a JAL
: statement like a "filename" an error status if the designated
: filename does not exist or is locked preventing access ? : Is it possible to detect specific error codes on execution or do you need to
: capture the output in some manner and then lexically parse that output for
: error strings ? : Thanks, : Jim
|
