Re: QUIT and ABORT

On 2025-05-17 06:56, dxf wrote:

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?

You wrote: "THROW handles -56 by jumping to Core QUIT". Then the test should fail. But as you now show, you only meant the case where there is no user exception frame in the exception stack.

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

Okay, these cases are compliant.

    1 2 3 -56 throw
     ok  1 2 3 <
    1 2 3 -1 throw
     ok

This special handling of `-56` is inconsistent, not justified by practice, and complicates implementations.
Yes, in some scenarios (such as interactive work) you may prefer this behavior, but for *any* uncaught exceptions. So, special handling of `-56` won't help you at all.

  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.
 

As I already mentioned, there are no special handling, it only specifies error messages:
   -1 — the empty message (no message);
   -2 — a program-defined message (from last executed `abort"`);
   any other — an implementation defined message concerning the error conditions.
Except for the message text, all actions are the same regardless of the error code.
--
Ruvim