9 The optional Exception word set

9.1 Introduction

9.2 Additional terms and notation

None.

9.3 Additional usage requirements

9.3.1 THROW values

The THROW values {-255...-1} shall be used only as assigned by this standard. The values {-4095...-256} shall be used only as assigned by a system.

Programs shall not define values for use with THROW in the range {-4095...-1}.

9.3.2 Exception frame

An exception frame is the implementation-dependent set of information recording the current execution state necessary for the proper functioning of CATCH and THROW. It often includes the depths of the data stack and return stack.

9.3.3 Exception stack

A stack used for the nesting of exception frames by CATCH and THROW. It may be, but need not be, implemented using the return stack.

9.3.4 Possible actions on an ambiguous condition

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

See: 3.4.4 Possible actions on an ambiguous condition.

Table 9.1: THROW code assignments

Code Reserved for Code Reserved for

-1ABORT
-2ABORT"
-3stack overflow
-4stack underflow
-5return stack overflow
-6return stack underflow
-7do-loops nested too deeply during execution
-8dictionary overflow
-9invalid memory address
-10division by zero
-11result out of range
-12argument type mismatch
-13undefined word
-14interpreting a compile-only word
-15invalid FORGET
-16attempt to use zero-length string as a name
-17pictured numeric output string overflow
-18parsed string overflow
-19definition name too long
-20write to a read-only location
-21unsupported operation
(e.g., AT-XY on a too-dumb terminal)
-22control structure mismatch
-23address alignment exception
-24invalid numeric argument
-25return stack imbalance
-26loop parameters unavailable
-27invalid recursion
-28user interrupt
-29compiler nesting
-30obsolescent feature
-31>BODY used on non-CREATEd definition
-32invalid name argument (e.g., TO name)
-33block read exception
-34block write exception
-35invalid block number
-36invalid file position
-37file I/O exception
-38non-existent file
-39unexpected end of file
-40invalid BASE for floating point conversion
-41loss of precision
-42floating-point divide by zero
-43floating-point result out of range
-44floating-point stack overflow
-45floating-point stack underflow
-46floating-point invalid argument
-47compilation word list deleted
-48invalid POSTPONE
-49search-order overflow
-50search-order underflow
-51compilation word list changed
-52control-flow stack overflow
-53exception stack overflow
-54floating-point underflow
-55floating-point unidentified fault
-56QUIT
-57exception in sending or receiving a character
-58[IF], [ELSE], or [THEN] exception
-59ALLOCATE
-60FREE
-61RESIZE
-62CLOSE-FILE
-63CREATE-FILE
-64DELETE-FILE
-65FILE-POSITION
-66FILE-SIZE
-67FILE-STATUS
-68FLUSH-FILE
-69OPEN-FILE
-70READ-FILE
-71READ-LINE
-72RENAME-FILE
-73REPOSITION-FILE
-74RESIZE-FILE
-75WRITE-FILE
-76WRITE-LINE
-77Malformed xchar
-78SUBSTITUTE
-79REPLACES

9.3.5 Exception handling

There are several methods of coupling CATCH and THROW to other procedural nestings. The usual nestings are the execution of definitions, use of the return stack, use of loops, instantiation of locals and nesting of input sources (i.e., with LOAD, EVALUATE, or INCLUDE-FILE).

When a THROW returns control to a CATCH, the system shall un-nest not only definitions, but also, if present, locals and input source specifications, to return the system to its proper state for continued execution past the CATCH.

9.4 Additional documentation requirements

9.4.1 System documentation

9.4.1.1 Implementation-defined options

9.4.1.2 Ambiguous conditions

  • no additional requirements.

9.4.1.3 Other system documentation

  • no additional requirements.

9.4.2 Program documentation

  • no additional requirements.

9.5 Compliance and labeling

9.5.1 Forth-2012 systems

The phrase "Providing the Exception word set" shall be appended to the label of any Standard System that provides all of the Exception word set.

The phrase "Providing name(s) from the Exception Extensions word set" shall be appended to the label of any Standard System that provides portions of the Exception Extensions word set.

The phrase "Providing the Exception Extensions word set" shall be appended to the label of any Standard System that provides all of the Exception and Exception Extensions word sets.

9.5.2 Forth-2012 programs

The phrase "Requiring the Exception word set" shall be appended to the label of Standard Programs that require the system to provide the Exception word set.

The phrase "Requiring name(s) from the Exception Extensions word set" shall be appended to the label of Standard Programs that require the system to provide portions of the Exception Extensions word set.

The phrase "Requiring the Exception Extensions word set" shall be appended to the label of Standard Programs that require the system to provide all of the Exception and Exception Extensions word sets.

9.6 Glossary

9.6.1 Exception words

9.6.2 Exception extension words

ContributeContributions

ruvavatar of ruv [260] Exception word set is not optional any moreComment2022-08-18 13:50:15

On the 2017 standard meeting the Exception word set was made mandatory to make it possible to remove some ambiguous conditions.

Could somebody point out the corresponding proposal and/or rationale for that?

An alternative way could be to remove the ambiguous conditions in the Exception word set only (by updating the corresponding core sections), or conditionally specify behavior in the core sections, i.e. to throw an exception if the Exception word set is implemented, and declare an ambiguous condition otherwise.

AntonErtlavatar of AntonErtl

I was tasked with drafting the change, but apparently did not make a proposal for it. But the editor has implemented the intention of the committee: In forth17-1 it says "The optional Exception word set", while in 18-1 it says "The Exception word set".

The rationale was that we wanted to get rid of ambiguous conditions, and in many cases this would have meant specifying one behaviour for a Forth system without exception wordset, and specifying a different behaviour for a Forth system with exception wordset, which would complicate the standard, and would make it harder to use (a standard program would have to consider both behaviours). The cost is that even small systems now have to implement CATCH and THROW, but given that these words are cheap to implement, we decided that the benefit is worth this cost.

The alternatives you suggest would run counter to the intention of reducing the ambiguous conditions, and they are an example of the complications we avoid by making the exception wordset mandatory.

ruvavatar of ruv

Actually, I agree. It just useful to see a comparison of different solution, and a clear list of proposed changes.

a standard program would have to consider both behaviours.

If a program relies on the Exception word set (e.g. it uses catch), it have to consider only one behavior, since it cannot work on the systems that don't provide the Exception word set. If the program doesn't use catch, it doesn't consider any specific behavior in the corresponding cases at all.


Having the Exception word set mandatory, don't you think that CORE ABORT and CORE ABORT" should be removed, and their EXCEPTION versions and THROW should be corrected/rewritten?

AntonErtlavatar of AntonErtl

Even if the program did not contain CATCH, it would have a different (unambiguous) meaning with the exception wordset and be ambiguous without.

Having the Exception word set mandatory, don't you think that CORE ABORT and CORE ABORT" should be removed, and their EXCEPTION versions and THROW should be corrected/rewritten?

Yes, something like that.

Reply New Version