if (userRequest = "A") try add record1; onException myErrorHandler(12); end end
In general, a try block allows your program to continue processing even if an error occurs.
The try block may include an onException clause, as shown earlier. That clause is invoked if one of the earlier statements in the try block fails; but in the absence of an onException clause, an error in a try block causes invocation of the first statement that immediately follows the try block.
EGL provides a series of system exceptions to indicate the specific nature of a runtime problem. Each of these exceptions is a dictionary from which you can retrieve information, but your retrieval is always by way of the system variable SysLib.currentException (also a dictionary), which lets you access the exception thrown most recently in the run unit.
if (userRequest = "A") try add record1; onException case (SysLib.currentException.code) when (FileIOException) myErrorHandler(12); otherwise myErrorHandler(15); end end end
In this case, FileIOException is a constant, which is equivalent to the string value "com.ibm.egl.FileIOException". The EGL exception constant is always equivalent to the last qualifier in a string that begins "com.ibm.egl".
It is strongly recommended that you access the exception fields only in an onException block. The run unit terminates if your code accesses SysLib.currentException when no exception has occurred.
if (userRequest = "A") try add record01; onException case (SysLib.currentException.code) when ("com.ibm.egl.SQLException") if (SysLib.currentException.sqlcode == -270) myErrorHandler(16); else myErrorHandler(20); end otherwise myErrorHandler(15); end end end
For details on the system exceptions, see EGL system exceptions.
Processing of numeric overflows is not affected by the presence of a try block. For details on those kinds of error, see VGVar.handleOverflow.
if (userRequest = "B") try myVariable = myABC(); onException myErrorHandler(12); end end
EGL provides error-related system variables that are set in a try block either in response to successful events or in response to non-terminating errors. The values in those variables are available in the try block and in code that runs subsequent to the try block, and the values in most cases are restored after a converse, if any.
If you are running in CICS®, values are also assigned to the CICS DL/I status variables (DLIVar.cicsError, DLIVar.cicsCondition, and DLIVar.cicsRestart).
EGL runtime does not set the DL/I-related variables listed earlier after your code accesses a GSAM file or an IMS message queue access. That access is considered to be serial-file access. To gain access to additional status information in those cases, use the appropriate PCB record. For an overview, see EGL support for runtime PSBs and PCBs. For details on particular types of PCB records, see Record types and properties.
An error code is assigned to sysVar.errorCode in the case of a non-terminating numeric overflow, as described in VGVar.handleOverflow; but a successful arithmetic calculation does not affect any error-related system variable.
The EGL runtime does not change the value of any error-related variables when statements run outside of a try block. Your program, however, may assign a value to an error-related variable outside of a try block.
In relation to DL/I, a hard error is any non-blank status code other than GA, GB, GD, GE,GK, or II, In relation to GSAM, a hard error is any non-blank status code other than GB. In relation to IMS, a hard error is any non-blank status code other than QC, QD, CE, CF, CG, CI, CJ, CK, or CL.
The default setting of that variable is dependent on the value of the property handleHardIOErrors , which is available in generatable logic parts like programs, libraries, and pageHandlers. The default value for the property is yes, which sets the initial value of the variable sysVar.handleHardIOErrors to 1.
If either a hard or soft I/O error occurs outside of a try block, the generated program presents an error message, if possible, and ends.
If you are accessing DB2® directly (not through JDBC), the sqlcode for a hard error is 304, 802, or less than 0.
recordName is IOerrorValue recordName not IOerrorValue
If you don't use the logical expressions with I/O error values and then change database management systems, you may need to modify and regenerate your program. In particular, it is recommended that you use the I/O error values to test for errors rather than the value of sysVar.sqlcode or sysVar.sqlState. Those values are dependent on the underlying database implementation.