From: ruvim.pinka@gmail.com   
      
   On 2025-05-06 14:12, dxf wrote:   
   > Irrespective of the merits such a change to the spec for THROW would   
   > be not be practical given most systems appear to use ANS' QUIT-based   
   > exception handler.  But for new implementers or the curious here is   
   > how I organised mine and which is readily changeable.   
   >   
   >   
   > \ return to OS with exit code   
   > : RETURN ( code -- ) ... ;   
   >   
   > \ perform ANS QUIT   
   > : (quit) ( -- )  r0 @ rp! reset normal /interpret   
   >    begin cr (refill) drop interpret state? 0= if (vstat)   
   >    @execute then again ;   
   >   
   > \ exit to OS or back to forth   
   > : ?return ( code -- )  turnkey? if return then drop (quit) ;   
      
   Returning to OS can be useful not only for a turnkey program, but also   
   for batch mode, in which the Forth system must return to the OS on any   
   uncaught error.   
      
   A possible use-case in Linux shell:   
      
      ./generate-forth-program params | forth --batch-mode   
      
   since you probably prefer not to interpret the following lines if there   
   an error occurs when defining a word in some line.   
      
      
   >   
   > \ clear data stacks   
   > : (abort) ( i*x -- )  s0 @ sp!  fs0 @ fsp !  1 ?return ;   
   >   
   > \ part of THROW   
   > : error ( n -- )   
   >    -1 of (abort) then   
   >    -2 of boot cell+ @ 0= if .error then   
   >       space errmsg 2@ type (abort) then   
   >    ."  THROW #" @base decimal swap . !base (abort) ;   
   >   
   > : QUIT ( -- )  0 ?return ;  \ QUIT not trapped   
   >   
   > \ QUIT is not trapped in DX-Forth but may be made so by   
   > \ adding  -56 of 1 ?return then  to 'error' and defining   
   > \ : QUIT  -56 throw ;   
      
      
   I use `quit` only for testing and debugging. And I expect to get into   
   the Forth text interpreter (Forth shell) exactly in the current program   
   state (as far as possible).   
      
   If `quit` simply calls `-56 throw`, the program state will probably   
   change (due to actions after `catch` in the program, including restoring   
   the data stack depth in `throw`) when you get into the Forth shell.   
   Also, there is a chance that you will not get into the Forth shell at   
   all if the program does not re-throw the error in some places.   
      
   So I would not recommend the suggested deviation in the `quit` behavior   
   even for new implementers, since this brakes the well-known expectation   
   from `quit`. A better way is to introduce another word with desired   
   behavior deviation.   
      
      
      
   >   
   > : ?ABORT ( flag c-addr u -- )   
   >    rot if errmsg 2! -2 throw then 2drop ;   
   >   
   > : (abort") ( flag -- )  r> count 2dup + >r ?abort ;   
   >   
   > : ABORT"  state @ if postpone (abort") ," end   
   >    postpone s" ?abort ; immediate   
   >   
   > : ABORT  -1 throw ;   
   >   
   >   
      
      
      
   --   
   Ruvim   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)