Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #26720 > unrolled thread

ABORT" ABORT QUIT THROW and all that

Back to article view | Back to comp.lang.forth

Contents

  ABORT" ABORT QUIT THROW and all that albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-28 13:12 +0000
    Re: ABORT" ABORT QUIT THROW and all that "Ed" <invalid@invalid.com> - 2013-10-29 16:01 +1100
      Re: ABORT" ABORT QUIT THROW and all that Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 16:52 +0100
        Re: ABORT" ABORT QUIT THROW and all that "Ed" <invalid@invalid.com> - 2013-10-30 12:01 +1100
    Re: ABORT" ABORT QUIT THROW and all that "Ed" <invalid@invalid.com> - 2013-11-02 12:55 +1100

#26720 — ABORT" ABORT QUIT THROW and all that

I'm experimenting with a turnkey program that is to be distributed
without assuming the Forth that generates it is installed or
documented on the run time system.

Normally I use 1000 series errors (1001 1002 1003) etc
for user induced error conditionsm then meticulously document them.

Now in this situation I decided to use ABORT" instead.
I hated it because it uses inline strings. And I've the
feeling I somehow don't "get" it. So if the following is
confusing it is because I am.

It seems to be a bit of a missnomer. It is *not* an
ABORT adorned with a message. All ABORT" signify situations
where I want to give the user a second chance, after he
has seen the message.
In other words a ABORT" is bound to be caught, not abort.
Fortunately the standard defines ABORT" as a THROW with
a special code.

Where is the entry point for a turnkey to be filled in?
A natural is ABORT. You want to run a Forth or a turnkey,
same idea. The first situation you fill in QUIT,
the second time you fill in CALCULATION.
An uncaught exception gets you in quit, or restarts the
calculation.

That is not too bad. Comes in the exception stack.
The standard assumes that the exception stack never goes
astray. That is good as far as it goes. Now systems are
known to catch pretty severe errors, like accessing
uninitialized memory. So there is another question.
Is there a good place to reinitialize the exception stack
in case of errors? Can it be safely done in either
QUIT or ABORT?

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [next] | [standalone]

#26733

Albert van der Horst wrote:
> ...
> It seems to be a bit of a missnomer. It is *not* an
> ABORT adorned with a message. All ABORT" signify situations
> where I want to give the user a second chance, after he
> has seen the message.
> In other words a ABORT" is bound to be caught, not abort.
> Fortunately the standard defines ABORT" as a THROW with
> a special code.

Left uncaught, ABORT" is required to execute ABORT which
in turn executes QUIT.  It is my understanding that if caught,
ABORT" will *not* print the message associated with it.

In my system uncaught errors eventually execute (abort) which
looks something like this:

    : (abort)  ( -- )  s0 @ sp! fs0 @ fsp ! ... quit ;

Typically a turnkey would modify QUIT so that the app exits
back to the OS, perhaps with an error code.

[toc] | [prev] | [next] | [standalone]

#26742

Ed wrote:

> Albert van der Horst wrote:
>> ...
>> It seems to be a bit of a missnomer. It is *not* an
>> ABORT adorned with a message. All ABORT" signify situations
>> where I want to give the user a second chance, after he
>> has seen the message.
>> In other words a ABORT" is bound to be caught, not abort.
>> Fortunately the standard defines ABORT" as a THROW with
>> a special code.
> 
> Left uncaught, ABORT" is required to execute ABORT which
> in turn executes QUIT.  It is my understanding that if caught,
> ABORT" will *not* print the message associated with it.

ABORT" throws -2 (see 9.6.2.0680).  Thus it can be distinguished from ABORT, 
and the standard says that the message ccc should be displayed if there is 
no corresponding CATCH.

: test true abort" blabla" ;  ok
test 
:2: blabla
>>>test<<<
Backtrace:
$7F445C4E6320 throw 
$7F445C550E38 c(abort") 

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#26753

Bernd Paysan wrote:
> Ed wrote:
>
> > Albert van der Horst wrote:
> >> ...
> >> It seems to be a bit of a missnomer. It is *not* an
> >> ABORT adorned with a message. All ABORT" signify situations
> >> where I want to give the user a second chance, after he
> >> has seen the message.
> >> In other words a ABORT" is bound to be caught, not abort.
> >> Fortunately the standard defines ABORT" as a THROW with
> >> a special code.
> >
> > Left uncaught, ABORT" is required to execute ABORT which
> > in turn executes QUIT.  It is my understanding that if caught,
> > ABORT" will *not* print the message associated with it.
>
> ABORT" throws -2 (see 9.6.2.0680).  Thus it can be distinguished from ABORT,
> and the standard says that the message ccc should be displayed if there is
> no corresponding CATCH.
>
> : test true abort" blabla" ;  ok
> test
> :2: blabla
> >>>test<<<
> Backtrace:
> $7F445C4E6320 throw
> $7F445C550E38 c(abort")

I don't suggest otherwise.

IIUC, Albert wants ABORT" to print the message if flag is non-zero after which
he can choose to catch the exception (?)

AFAIK, ANS ABORT" doesn't permit this.

[toc] | [prev] | [next] | [standalone]

#26781

Albert van der Horst wrote:
> ...
> Where is the entry point for a turnkey to be filled in?
> A natural is ABORT. You want to run a Forth or a turnkey,
> same idea. The first situation you fill in QUIT,
> the second time you fill in CALCULATION.
> An uncaught exception gets you in quit, or restarts the
> calculation.

My system has a variable BOOT and flags and to indicate whether
the application running is forth, a compilerless turnkey, or turnkey
with compiler.  The error routine interrogates BOOT etc and takes
appropriate action depending on the environment.  E.g. if the app is
a compilerless turnkey, error just prints the ABORT" message,
leaving out details such as last word parsed, screen/file location etc
which a) wouldn't apply in this situation and b) the code for it isn't
even resident.

It's more complicated than simply patching COLD and QUIT but
probably unavoidable given the turnkey options and memory configurations
my system needs to support.  On the plus side, I can TURNKEY and
remain in forth confident that a keyboard mistake or executing COLD
won't result in a surprise!

> ...
> Is there a good place to reinitialize the exception stack
> in case of errors? Can it be safely done in either
> QUIT or ABORT?

I initialize the error handler with  0 CATCHER ! (called HANDLER
on some systems).  This occurs in COLD and QUIT just after the
return stack pointer has been initialized.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web