Re: QUIT and ABORT

On 16/05/2025 9:12 pm, Ruvim wrote:

On 2025-05-16 12:19, dxf wrote:

On 16/05/2025 3:53 pm, Ruvim wrote:

On 2025-05-15 06:14, dxf wrote:

...
>
CATCH has already done the damage.  It would be naive for a programmer
to assume he can re-throw QUIT and it will be as if nothing ever happened.

>
My point is that such a word is completely useless.

>
The goal is catching fish.  What happens to the ones you catch and then
decide to throw it back in is relatively minor.  If they end up a bit
worse for wear that's just how it is.

 
Could you please provide a practical use case for this? The standard `quit` is useful for debugging, at the least.
 
If your goal is to catch `quit` in your program, just redefine `quit` accordingly. Then, of course, the system is not a standard Forth system after loading your program (see 4.2.2).
 
 
 

Presumably an implementer of a catchable QUIT actually wants it caught.
The question then is what can he do for the occasions when he wants it
impervious to CATCH and there are solutions for that.
>

>
What solution do you mean?

>
Default behaviour of QUIT is Core QUIT.  THROW handles -56 by jumping to
Core QUIT.

 
If you make `throw` do this regardless of whether a user's exception frame exists in the exception stack, you make the `-56` error code uncatchable. So, the following test case will fail:
 
  t{  [: -56 throw ;] catch -> -56 }t
 
And what is the benefit?

Why should it fail?

  [: -56 throw ;] catch  ok  -56 <

  [: -1 throw ;] catch  ok  -1 <

  1 2 3 -56 throw
    ok  1 2 3 <

  1 2 3 -1 throw
    ok

 The application programmer then has the option of making QUIT
catchable by defining:
>
   : QUIT -56 THROW ;
>

 
But this option already exists. There is no need to specially handle `-56` in `throw`.

By that argument there's no reason to specially handle -1 in THROW.