188.8.131.525 THROW EXCEPTION
If any bits of n are non-zero, pop the topmost exception frame from the exception stack, along with everything on the return stack above that frame. Then restore the input source specification in use before the corresponding CATCH and adjust the depths of all stacks defined by this standard so that they are the same as the depths saved in the exception frame (i is the same number as the i in the input arguments to the corresponding CATCH), put n on top of the data stack, and transfer control to a point just after the CATCH that pushed that exception frame.
If the top of the stack is non zero and there is no exception frame on the exception stack, the behavior is as follows:
Otherwise, the system may display an implementation-dependent message giving information about the condition associated with the THROW code n. Subsequently, the system shall perform the function of 6.1.0670 ABORT (the version of ABORT in the Core word set).
KEY DUP [CHAR] Q = IF 1 THROW THEN ;
?DUP IF ( exc# ) \ 0 THROW is no-op
HANDLER @ RP! ( exc# ) \ restore prev return stack
R> HANDLER ! ( exc# ) \ restore prev handler
R> SWAP >R ( saved-sp ) \ exc# on return stack
SP! DROP R> ( exc# ) \ restore stack
\ Return to the caller of CATCH because return
\ stack is restored to the state that existed
\ when CATCH began execution
AlexDyachenko  The value of STATE should be restoredProposal2017-09-03 11:07:49
AndrewRead  EXCEPTION LOCALsProposal2017-10-28 07:04:49
MitraArdron  THROW: text doesn't match implementation exampleComment2020-12-06 08:05:30
I think the text needs updating - it is not clear what happens when the value is zero, though the implementation example is.
I think this is particularly imporant as this differs from other implementations of THROW, for example in eForth where it is always triggered , i.e. there is no "?DUP IF"
JimPeterson  Throwing past DO/LOOPComment2021-04-19 19:06:28
I didn't implement my
LOOP to store limits/counters on the return stack (limited system, no room there, the standard does not require it). If I were to
THROW up through a
LOOP (particularly a nested one), using the above specification for
THROW as my bare-bones attempt at implementing it, I know that "an ambiguous condition" would then most certainly exist.
This is my own fault, but shouldn't there at least be a note in the standard along the lines of "The system should implement an appropriate number of
UNROLL operations when throwing an exception up through
LOOP constructs."? For most systems, this is implied by adjusting the return stack, and systems implementors would just think "easy", but at least it would be explicitly stated.
Certainly, any similar user-made constructs have identical issues that are entirely the user's responsibility. Maybe this is an argument for making
THROW compatible with
DEFER!? How else would user code that acquires global resources properly interoperate in the presence of
ruv  Input source after THROWComment2023-02-15 22:50:52
In presence of the
restore-input words, it could appear that
throw should restore the state of the input source as it was before execution of the corresponding
catch, due to similar wording.
But actually the specification only requires that if a throw code is non zero, the input source is the same before and after execution of
catch. But the state of this input source may be changed.
Namely, the specification for
- (if n <> 0) "restore the input source specification in use before the corresponding CATCH" (emphasis added)
While the specification for
- "restore the input source specification to the state described by..." (emphasis added)
If the state of the input source were to be restored, the following test would show the same line "source: test" twice:
: test [: cr ." source: " source type cr ." next line: " refill cr . cr abort ;] catch drop ." source: " source type cr postpone \ ; test \ some other line
NB: the state of the input source can be only changed via
>in (directly or indirectly),
restore-input. No other way to change this state for a standard program.
Please correct me if I'm wrong somewhere. Otherwise, the wording should reflect this nuance more explicit, I think.
MitraArdron  Imlementation seems wrong for the "-2" caseSuggested reference implementation2023-08-03 10:30:03
If the top of the stack is -2 , and there is no handler, then THROW is supposed to display a message
I can't see how the reference implementation does that. It deals with the case of being called from inside a CATCH correctly as far as I can tell, but does not handle the case of HANDLER being empty - in fact if HANDLER=0 I think this would crash.
Note - I picked this up when the Hayes test suite failed its exception test set.