Table of Contents
6.08 Error Codes
Error Codes are grouped into categories.
|1- 99||Interpreter errors|
|100-199||Run time syntax errors|
|500-599||Run time errors|
|1000-1999||User generated errors|
- Syntax Error
The syntax is not understood by the interpreter.
- Missing closing quote
A string has not been closed properly.
Run Time Syntax Errors
- Parameter count error
The wrong number of parameters was supplied on a function or procedure call.
Run Time Errors
- File or directory not found
An attempt was made to open a file or directory that does not exist.
- File is not open
An attempt was made to access or close a file that is not open.
QBasic Run-Time Error Codes
|1||NEXT without FOR|
|3||RETURN without GOSUB|
|4||Out of DATA|
|5||Illegal function call|
|7||Out of memory|
|8||Label not defined|
|9||Subscript out of range|
|11||Division by zero|
|12||Illegal in direct mode|
|14||Out of string space|
|16||String formula too complex|
|18||Function not defined|
|20||RESUME without error|
|26||FOR without NEXT|
|27||Out of paper|
|29||WHILE without WEND|
|30||WEND without WHILE|
|35||Subprogram not defined|
|38||Array not defined|
|52||Bad file name or number|
|54||Bad file mode|
|55||File already open|
|56||FIELD statement active|
|57||Device I/O error|
|58||File already exists|
|59||Bad record length|
|62||Input past end of file|
|63||Bad record number|
|64||Bad file name|
|67||Too many files|
|71||Disk not ready|
|74||Rename across disks|
|75||Path/File access error|
|76||Path not found|
Rexx Error Messages
Failure during initialization:
An ERROR condition happens when there is some error that an add-on Function you call in a DLL, or (non-REXX) program that you run, encounters as a result of doing its work. For example, if you run some program that downloads a web page to a file, and it encounters a problem, an ERROR condition may occur.
If your script is not trapping FAILURE, but is trapping ERROR, then REXX will raise ERROR whenever it would otherwise raise FAILURE. In other words, if you want reported only critical errors with add-on DLLs or EXEs you run (but not other errors), then trap only FAILURE (not ERROR). If you want reported both critical and all other errors with add-on DLLs and EXEs, then you need trap only ERROR (not FAILURE).
ERROR error/sub-error numbers
Whenever an ERROR 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 ERROR 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 ERROR 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 an ERROR 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 ERROR condition, and what is the meaning of each combination of error/sub-error number.
65 Category: An untrapped ERROR condition occurred in a child script. Reginald-only. CONDITION('D') reports the script name, exact error, and line number.
40 An error in launching an executable.
1 An environment raised an ERROR condition when it was passed a command.
2 Your script tried to pass a command to an environment that does not exist and can't be autoloaded. 3 An executable (EXE) run by your script raised a FAILURE condition.
4 An exit handler raised an ERROR condition when you tried to pass a command to an Environment.
70 A FUNCDEF registered function was defined to return a str, char, or struct, but it did not return the expected item. This happens only if you ask to be informed of errors via the ERROR condition when you FUNCDEF the function.
For the four errors under category 40, the RXFUNCERRMSG() built-in may return a more informative error message than CONDITION('D').
Trapping ERROR in a child script
The Reginald interpreter allows you to trap an ERROR condition raised in any child script you call (as well as any other child script that the first child calls), if that script doesn't trap ERROR for itself.
Your script must use a CATCH ERROR instruction where you call the child script. If ERROR is then raised by the child script, the child script will abort on the line where ERROR occurs, and Reginald will raise ERROR in your script (on the line where you called the script). In this case, CONDITION('E') returns an error number of 65 to indicate that it was a child script (as opposed to your script) in which ERROR was raised. CONDITION('D') will return an error message that reports the name of the child script in which ERROR was raised, the line number where it occurred in the child script, and a reason why the condition was raised.
What this means is that, using the CATCH ERROR, if a child script doesn't handle ERROR for itself, you can force that child script to be aborted and have that ERROR automatically reported back to you by REXX.
Here is an example handler that would differentiate between ERROR raised in your script versus another script that you called:
CATCH ERROR IF CONDITION('E') == '65' THEN DO PARSE VALUE CONDITION('D') WITH . '"' scriptname '"' . 'line linenum ': ' reason /* CONDITION('M') is preferable to this SAY. */ SAY 'ERROR condition raised in "'|| scriptname ||'" at line' linenum ':' reason END ELSE /* CONDITION('M') is preferable to this SAY. */ SAY 'ERROR condition raised in this script:' CONDITION('D') RETURN
REXX Error codes
The first column in the following table lists the standard error numbers. The second column shows the corresponding error text. Error numbers between 51 and 99 are implementation-dependent.
Additional error information may be obtained by requesting the condition built-in function's optional description value.
|5||Machine resources exhausted|
|6||Unmatched “/*” or quote|
|7||WHEN or OTHERWISE expected|
|8||Unexpected THEN or ELSE|
|9||Unexpected WHEN or OTHERWISE|
|10||Unexpected or unmatched END|
|11||Control stack full|
|12||Clause too long|
|13||Invalid character in program|
|15||Invalid hexadecimal or binary string|
|16||Label not found|
|19||String or symbol expected|
|21||Invalid data on end of clause|
|22||Invalid character string|
|23||Invalid data string|
|24||Invalid TRACE request|
|25||Invalid sub-keyword found|
|26||Invalid whole number|
|27||Invalid DO syntax|
|28||Invalid LEAVE or ITERATE|
|29||Environment name too long, or not found|
|30||Name or string too long|
|31||Name starts with number or “.”|
|33||Invalid expression result|
|34||Logical value not 0 or 1|
|36||Unmatched “(” in expression|
|37||Unexpected “,” or “)”|
|38||Invalid template or pattern|
|40||Incorrect call to routine|
|41||Bad arithmetic conversion|
|43||Routine not found|
|44||Function did not return data|
|45||No data specified on function RETURN|
|46||Invalid variable reference|
|48||Failure in system service|