Whenever a FAILURE condition is raised, an error number, and possibly a sub-error number as well, is associated with that instance of the condition being raised. Each one of the numerous reasons for FAILURE being raised will produce a different combination of error/sub-error numbers. So, by checking the error/sub-error numbers, you can deduce exactly what went wrong in your script (ie, why the FAILURE condition was raised).

Your handler can use the CONDITION() built-in function's 'E' option to fetch the error and sub-error numbers associated with a given instance of that condition. CONDITION('E') will return the two numbers separated by a dot. For example, 80.81 will be returned for a FAILURE condition raised because an environment chose to raise this condition when you passed the environment a particular command. You'd have to consult the documentation with the environment to determine why it may have reacted this way to that particular command.

The error number can be thought of as a "general category number". And the sub-error number is a specific error within that category.

The following chart lists the error and sub-error numbers associated with the FAILURE condition, and what is the meaning of each combination of error/sub-error number.

65	Category: An untrapped FAILURE condition occurred in a child script. Reginald-only. CONDITION('D') reports the script name, exact error, and line number
80	Category: An error in an environment. Reginald-only
80.1	An environment raised a FAILURE condition when it was passed a command
80.3	An executable (EXE) launched by your script raised a FAILURE condition
80.4	An exit handler raised a FAILURE condition when you tried to pass a command to an Environment
81	Category: An error in registering a function in a DLL/EXE. Reginald-only
81.10	There is another function already registered with the same REXX name
81.40	The DLL (in which the function is supposed to be located) can't be found
81.50	The function name can't be found in the DLL

For errors, 81.40 and 81.50, the RXFUNCERRMSG() built-in may return a more informative error message than CONDITION('D').

A FAILURE condition can also be raised if you've issued an OPTIONS 'TRAP' instruction and are trapping FAILURE, and then you call some other script in which FAILURE is raised, but not trapped, in that child script. In this case, CONDITION('E') returns an error number of 65. (This is a Reginald-only feature). CONDITION('D') will return an error message that reports the name of the script in which FAILURE was raised, the line number where it occurred, and a reason why the condition was raised. Here is an example handler that would differentiate between FAILURE raised in your script versus another script that you called:

MyHandler:
   IF CONDITION('E') == '65' THEN DO
      PARSE VALUE CONDITION('D') WITH . '"' scriptname '"' . 'line ' linenum ': ' reason
      SAY 'FAILURE condition raised in "'|| scriptname ||'" at line' linenum ':' reason
   END
   ELSE DO
      SAY 'FAILURE condition raised at line' SIGL ':' CONDITION('D')
   END
   RETURN

When you're passing a command to some environment, or telling the operating system (ie, 'CMD' environment) to launch some program, the special variable RC will be set to any error message or number returned by the program you launch, or by the environment to which you pass a command. This variable is set regardless of whether you have your own FAILURE handler, so you can always check the RC variable to see what error message or number a program or environment has returned. Often, the number 0 will be returned to indicate success, but this is just a guideline.