- Foreword
- Proposals Process
- 200x Membership
- 1 Introduction
- 2 Terms, notation, and references
- 3 Usage requirements
- 4 Documentation requirements
- 5 Compliance and labeling
- 6 Glossary
- 7 The optional Block word set
- 8 The optional Double-Number word set
- 9 The optional Exception word set
- 10 The optional Facility word set
- 11 The optional File-Access word set
- 12 The optional Floating-Point word set
- 13 The optional Locals word set
- 14 The optional Memory-Allocation word set
- 15 The optional Programming-Tools word set
- 16 The optional Search-Order word set
- 17 The optional String word set
- 18 The optional Extended-Character word set
- Annex A: Rationale
- Annex B: Bibliography
- Annex C: Compatibility analysis
- Annex D: Portability guide
- Annex E: Reference Implementations
- Annex F: Test Suite
- Annex H: Alphabetic list of words
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.
| Code Reserved for | Code Reserved for | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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
- Values used in the system by 9.6.1.0875 CATCH and 9.6.1.2275 THROW (9.3.1 THROW values, 9.3.4 Possible actions on an ambiguous condition).
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
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.
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.
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?
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.
ruv
For reference, I collect the cases where ambiguous condition can be eliminated in the issue "Eliminating of some ambiguous conditions" on ForthHub/standard-evolution.