ANS Error Codes

Chris Jakeman

unread,

Dec 22, 1995, 3:00:00 AM12/22/95

to

Hi,

The ANS Forth document lists, in the section on the optional Exception word
set, 58 error codes to be used by THROW. I have got to grips with most of
these, but can anyone enlighten me on what is meant by:

-12 argument type mismatch
-24 invalid numeric argument
-48 invalid POSTPONE
-56 QUIT

Jim Schneider

unread,

Dec 29, 1995, 3:00:00 AM12/29/95

to

In article <819640...@apvpeter.demon.co.uk> cjak...@apvpeter.demon.co.uk

(Chris Jakeman) writes:
>Hi,
>
>The ANS Forth document lists, in the section on the optional Exception word
>set, 58 error codes to be used by THROW. I have got to grips with most of
>these, but can anyone enlighten me on what is meant by:
>
> -12 argument type mismatch
> -24 invalid numeric argument
> -48 invalid POSTPONE
> -56 QUIT
>

-<sig deleted>-

Well, here's my two cents worth:

-12 THROW -- Argument type mismatch. This is possibly useful on FORTH systems
that bother to do argument typing. This exception could be thrown if you
(for example) gave an operator that expected signed quantities unsigned ones
instead. About the only place I could see this one really being used is:
Words that require a positive signed number could raise this on being given a
negative number.
and:
Words that use tokens that resolve addresses (execution tokens being but the
most immediately obvious) could throw this value on being given a number that
is not a valid address resolving token. In addition to the obvious EXECUTE,
@ and !, and their relatives, could also raise this, as could any of the
control flow words that expect an address resolving token (called a *-sys
in the Standard, where * is a glob pattern).

-24 THROW -- Invalid numeric argument. This is probably more reasonable for
the first example I gave above. This error means that an argument to a word
is out of range, or is in some other way invalid. For example, -16 SQRT
(if SQRT is defined on your system to return the integer square root of the
top of stack item) could very well THROW this value.

-48 THROW -- Invalid POSTPONE. The standard specifies in several places that
some words can't be portably POSTPONEd. It creates "an ambigous condition"
to postpone TO, for example, because it parses the input stream to find the
name of the word that it affects, even when it is invoked in a definition
(although the Standard doesn't explicitly state, this means that TO would
almost have to be implemented as an immediate word). Thus, it could be
an invalid operation to POSTPONE TO, and this value may be THROWn.

-56 THROW -- QUIT. The Standard seems to be explicitly allowing QUIT to
be implemented as:

: QUIT -56 THROW ;

Since in a lot of FORTH systems the outer interpreter (the one that interprets
what you type in) is implemented in QUIT, I don't think that this will catch
on. This usage would unnecessarily complicate either CATCH or THROW.

I hope this helped someone.

Wonyong Koh

unread,

Jan 3, 1996, 3:00:00 AM1/3/96

to

ja...@netcom.com (Jim Schneider) wrote:

>In article <819640...@apvpeter.demon.co.uk> cjak...@apvpeter.demon.co.uk
>(Chris Jakeman) writes:
>>Hi,
>>
>>The ANS Forth document lists, in the section on the optional Exception word
>>set, 58 error codes to be used by THROW. I have got to grips with most of
>>these, but can anyone enlighten me on what is meant by:
>>
>> -12 argument type mismatch
>> -24 invalid numeric argument
>> -48 invalid POSTPONE
>> -56 QUIT
>>
>-<sig deleted>-

>Well, here's my two cents worth:

>-56 THROW -- QUIT. The Standard seems to be explicitly allowing QUIT to
>be implemented as:

>: QUIT -56 THROW ;

>Since in a lot of FORTH systems the outer interpreter (the one that interprets
>what you type in) is implemented in QUIT, I don't think that this will catch
>on. This usage would unnecessarily complicate either CATCH or THROW.

I think that '-56 THROW' is devised to return control to user input
device conveniently. For example, you can do

[IF] -56 THROW [THEN]

to stop loading a Forth program without any error message.

Wonyong Koh
wy...@pado.krict.re.kr

Loring Craymer

unread,

Jan 3, 1996, 3:00:00 AM1/3/96

to

Shortly after CATCH and THROW were added to the BASIS document (I think that it
was the meeting after), Mitch Bradley proposed a list of just under 50 THROW codes
which represented the ambiguous conditions described in the document. The wording
("argument type mismatch" and the like) represents the wording of the document at
that time. No implementation is required to use any or all of these codes.

Actually, the outer interpreter must CATCH all exceptions. From an implementation
standpoint, it is actually much more convenient to implement QUIT as a special
type of exception and have the outer interpreter be distinct from QUIT. This is
also useful for background tasks in a multitasking system (not covered by the
Standard): obviously, you usually don't want a background task to request
terminal input if it crashes.

|> I think that '-56 THROW' is devised to return control to user input
|> device conveniently. For example, you can do
|>
|> [IF] -56 THROW [THEN]
|>
|> to stop loading a Forth program without any error message.
|>
|> Wonyong Koh
|> wy...@pado.krict.re.kr
|>
|>

You have to be careful about reading too much into the list of THROW codes. Where
we tried to keep the number of word definitions to a minimum, we also tried to
list all ambiguous conditions and assign a THROW code to each one. Implementors
are not required to use any or all of the THROW codes; the relevant wording from
section 9.3.5 is:

"A system choosing to execute THROW when detecting one of the ambiguous conditions
listed in table 9.3.6 shall use the throw code there."

The restriction on implementors is that they must use a specific THROW code if
they choose to support CATCHing of the corresponding exception.

QUIT is given an error code for completeness--my argument was that any operation
which aborted processing should have a corresponding THROW code, and the committee
accepted this with very little discussion. IMNSHO, I believe that any system
which implements CATCH and THROW should make sure that CATCH handles all
processing aborts. For any real application, the implementation language should
not be forced on the user: if processing is aborted from within an application,
the application should gracefully return control to the user and not provide
him or her with a meaningless prompt (OK? What is OK? Why has my graphical
application lost its windows? I guess that it's time to buy a better word
processor (spreadsheet, DBMS, etc.)--I will not tolerate shoddy software!). The
traditional weak link in Forth applications is the use of the system's interpreter
in lieu of writing a custom interface appropriate to the application. [This is
not to say that Forth should not be available as a scripting language: I'm a
great fan of incorporating scripting languages in applications. However, it should
also be possible for the naive user to remain naive about any such capabilities.]
Professionally written software should have a professional appearance!

Loring Craymer

Jim Schneider

unread,

Jan 9, 1996, 3:00:00 AM1/9/96

to

In article <4cbc7v$n...@nis.dacom.co.kr> wy...@pado.krict.re.kr writes:
>ja...@netcom.com (Jim Schneider) wrote:
>
>>In article <819640...@apvpeter.demon.co.uk> cjak...@apvpeter.demon.co.uk
>>(Chris Jakeman) writes:
>>>Hi,
>>>

-<stuff deleted>-

>
>I think that '-56 THROW' is devised to return control to user input
>device conveniently. For example, you can do
>
> [IF] -56 THROW [THEN]
>
>to stop loading a Forth program without any error message.
>
>Wonyong Koh
>wy...@pado.krict.re.kr
>
>

Why not just use:

[IF] QUIT [THEN]

This will also stop loading a FORTH program without any error message.