Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"I'm not afraid of dying, I just don't want to be there when it happens." -- Woody Allen


devel / comp.lang.forth / Re: Exception Handling in Standard Forth

SubjectAuthor
* Exception Handling in Standard ForthKrishna Myneni
+- Re: Exception Handling in Standard ForthS Jack
+* Re: Exception Handling in Standard ForthAnton Ertl
|+* Re: Exception Handling in Standard ForthKrishna Myneni
||`* Re: Exception Handling in Standard ForthAnton Ertl
|| `* Re: Exception Handling in Standard ForthRuvim
||  `* Re: Exception Handling in Standard ForthAnton Ertl
||   `- Re: Exception Handling in Standard ForthRuvim
|`* Re: Exception Handling in Standard ForthKrishna Myneni
| `* Re: Exception Handling in Standard ForthAnton Ertl
|  `- Re: Exception Handling in Standard ForthKrishna Myneni
`* Re: Exception Handling in Standard ForthKrishna Myneni
 `* Re: Exception Handling in Standard ForthNN
  +* Re: Exception Handling in Standard ForthKrishna Myneni
  |`* Re: Exception Handling in Standard ForthGerry Jackson
  | +* Re: Exception Handling in Standard ForthKrishna Myneni
  | |`* Re: Exception Handling in Standard ForthGerry Jackson
  | | `- Re: Exception Handling in Standard ForthAnton Ertl
  | `- Re: Exception Handling in Standard ForthAnton Ertl
  `- Re: Exception Handling in Standard ForthAnton Ertl

1
Exception Handling in Standard Forth

<sqn9tt$fq2$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15946&group=comp.lang.forth#15946

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Exception Handling in Standard Forth
Date: Fri, 31 Dec 2021 10:08:28 -0600
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <sqn9tt$fq2$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 31 Dec 2021 16:08:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="bb11d30a90bc46b40d22924e2291d8d2";
logging-data="16194"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bwu/6X753oPXB0Mh11dQC"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.2.0
Cancel-Lock: sha1:E6kSQolmP7Uv3s5Oqr4JffuXvZk=
Content-Language: en-US
 by: Krishna Myneni - Fri, 31 Dec 2021 16:08 UTC

Below is a bit of explication on the topic of exception handling in
Standard Forth, which some readers here may find useful. Quotations (in
coding) have a useful application to exception handling, and I give an
example below. To paraphrase Yoda,

"[In Forth], there is no TRY, only CATCH."

Within a definition, the typical way in which exceptions may be caught
for error handling is to use the following sequence.

['] WORDTOTRY CATCH ?DUP IF ... THEN

where WORDTOTRY is the name of the word which will be "TRYed" by CATCH.
The exception/error handler, in case of a THROW performed anywhere
within WORDTOTRY, is the code following CATCH, within the IF ... THEN
block. In the example above, the throw code (exception number) is
available on the stack for use by the error handler code within the IF
.... THEN block.

It is useful to contrast the Forth exception handling method with that
in C++, which uses the following sequence,

try{...}
catch( name1 ){...}
catch( name2 ){...}
....

Within the braces of "try{...}" one can include multiple statements,
from which any function call may perform a "throw( name )" causing an
immediate branch to the corresponding catch(name){...} block -- text
names are used in place of numeric throw codes, so each particular error
may have its own "catch" error handler.

In the Forth method shown above, CATCH is given a single word to "TRY".
For multiple words which may throw related errors, one may make a
compound definition, e.g. a named word or a quotation. Furthermore, the
single error handler following CATCH must examine all of the possible
throw codes, for which the handler wishes to take some action, generated
by the compound word or quotation -- this style of a single CATCH
exception handler dealing with multiple errors may also be used within a
C++ catch(){...} block.

My example of CATCH and THROW to handle exceptions from more than one
word is listed below. The application is for a user interface to a menu
of functions, each of which is represented by a single key command, e.g.
'Q' for Quit. If the user presses a key not corresponding to a menu
selection, an error is thrown. Also, some menu selections may not always
be available during execution -- when this occurs, choosing the
unavailable selection also causes an error to be thrown. The word
GET-PERFORM is used for obtaining a valid and available menu selection
and then performing it.

Note the use of CATCH within the definition of RETRY. Also not the use
of a quotation within the definition of GET-PERFORM.

--
Krishna

\ Notice: Google Groups will destroy the formatting, so apply your
\ desired punctuation.

: retry ( i*x xt -- j*x )
>r
BEGIN
r@ catch dup
WHILE
case
1 of ." Invalid Selection" endof
2 of ." Function Not Available" endof
endcase
cr
REPEAT
drop r> drop
;

: MenuCommands s" LR123ECHTXQ" ;

: valid? ( c -- c )
dup MenuCommands rot scan nip 0= if 1 throw then ;

: available? ( c -- c )
dup dup [char] T = swap [char] X = or
if 2 throw then ;

: get-perform ( -- )
[: key valid? available? ;] retry
." Performing " emit cr
;

cr
..( Select a menu function: ) MenuCommands type cr
get-perform

Re: Exception Handling in Standard Forth

<d75186c9-ac0d-4b97-8234-1f14aeee19c5n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15947&group=comp.lang.forth#15947

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ae9:ef4b:: with SMTP id d72mr24913121qkg.690.1640971150727;
Fri, 31 Dec 2021 09:19:10 -0800 (PST)
X-Received: by 2002:ac8:5756:: with SMTP id 22mr31108999qtx.370.1640971150525;
Fri, 31 Dec 2021 09:19:10 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Fri, 31 Dec 2021 09:19:10 -0800 (PST)
In-Reply-To: <sqn9tt$fq2$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:3f7a:20d0:f0b8:f2cc:4ab2:9ff8;
posting-account=V5nGoQoAAAC_P2U0qnxm2kC0s1jNJXJa
NNTP-Posting-Host: 2600:1700:3f7a:20d0:f0b8:f2cc:4ab2:9ff8
References: <sqn9tt$fq2$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d75186c9-ac0d-4b97-8234-1f14aeee19c5n@googlegroups.com>
Subject: Re: Exception Handling in Standard Forth
From: sdwjac...@gmail.com (S Jack)
Injection-Date: Fri, 31 Dec 2021 17:19:10 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 17
 by: S Jack - Fri, 31 Dec 2021 17:19 UTC

On Friday, December 31, 2021 at 10:08:32 AM UTC-6, Krishna Myneni wrote:
> It is useful to contrast the Forth exception handling method with that
> in C++ ...

More likely lead to a snipe hunt than anything useful;)

> My example of CATCH and THROW to handle exceptions from more than one
> word ...

A single CATCH can handle any and all THROWs below it.
Don't see the problem but confess to not spending much time
looking as existing CATCH/THROW hasn't caused me any pain.
(Even found a way to use it to catch definition faults which
most consider useless, which it is mostly, except when testing exception
conditions and don't want the run to abort on the forced failures.)
--
me

Re: Exception Handling in Standard Forth

<2022Jan3.143913@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16062&group=comp.lang.forth#16062

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Mon, 03 Jan 2022 13:39:13 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 55
Message-ID: <2022Jan3.143913@mips.complang.tuwien.ac.at>
References: <sqn9tt$fq2$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="d2ff4cf4d9565f5ed7aa38586fbd14d6";
logging-data="8985"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19fDaoMi6GgO4193T2ItdV3"
Cancel-Lock: sha1:2R8SWLRMTw1O5nVbtL3BbvVI7ME=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 3 Jan 2022 13:39 UTC

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>Within a definition, the typical way in which exceptions may be caught
>for error handling is to use the following sequence.
>
> ['] WORDTOTRY CATCH ?DUP IF ... THEN

My typical usage of CATCH is for cleaning up, and it follows the
scheme

save-state [: change-state do-something ;] catch restore-state throw

Of course it's also possible that you want to handle a particular
exception, and then you need to look at the ball instead of just
throwing it onwards.

>It is useful to contrast the Forth exception handling method with that
>in C++, which uses the following sequence,
>
>try{...}
>catch( name1 ){...}
>catch( name2 ){...}
>...
>
>Within the braces of "try{...}" one can include multiple statements,
>from which any function call may perform a "throw( name )" causing an
>immediate branch to the corresponding catch(name){...} block -- text
>names are used in place of numeric throw codes, so each particular error
>may have its own "catch" error handler.

One specific difference is that C++ (I think, certainly Java does it
that way) throws objects, and the catch clauses name classes that the
object may belong to (then the catch matches) or not, while Forth just
throws a non-zero cell (and the values -4095 to -1 are also reserved).

The typical use in standard Forth is to throw an integer, although I
have also seen a case (IIRC in Open Firmware) where the address of a
counted string is thrown (and the other end is expected to print this).

The benefit of the C++/Java method is that the object can contain
additional data that can be extracted by the catcher and the catcher
can make use of the data (e.g., which address was accessed in case of
a "invalid memory address" exception). Also, the classes form a
hierarchy, so one catcher can catch a number of related exceptions by
catching the superclass, while another catcher can catch some more
specific stuff.

However, given my typical use of CATCH, how often is this additional
functionality really needed in C++ or Java?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Exception Handling in Standard Forth

<sqve1k$5ii$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16085&group=comp.lang.forth#16085

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Mon, 3 Jan 2022 12:07:46 -0600
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <sqve1k$5ii$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me>
<2022Jan3.143913@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 3 Jan 2022 18:07:48 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="966ba64ce74c6c7fffb6f780c76dae67";
logging-data="5714"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+V9QaJ9elZzo7jjHtEucp1"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.2.0
Cancel-Lock: sha1:uY1H+DNj9nLyXG2ImpVefuqKdl4=
In-Reply-To: <2022Jan3.143913@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Krishna Myneni - Mon, 3 Jan 2022 18:07 UTC

On 1/3/22 07:39, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> Within a definition, the typical way in which exceptions may be caught
>> for error handling is to use the following sequence.
>>
>> ['] WORDTOTRY CATCH ?DUP IF ... THEN
>
> My typical usage of CATCH is for cleaning up, and it follows the
> scheme
>
> save-state [: change-state do-something ;] catch restore-state throw
>
> Of course it's also possible that you want to handle a particular
> exception, and then you need to look at the ball instead of just
> throwing it onwards.
>
>> It is useful to contrast the Forth exception handling method with that
>> in C++, which uses the following sequence,
>>
>> try{...}
>> catch( name1 ){...}
>> catch( name2 ){...}
>> ...
>>
>> Within the braces of "try{...}" one can include multiple statements,
>>from which any function call may perform a "throw( name )" causing an
>> immediate branch to the corresponding catch(name){...} block -- text
>> names are used in place of numeric throw codes, so each particular error
>> may have its own "catch" error handler.
>
> One specific difference is that C++ (I think, certainly Java does it
> that way) throws objects, and the catch clauses name classes that the
> object may belong to (then the catch matches) or not, while Forth just
> throws a non-zero cell (and the values -4095 to -1 are also reserved).
>
> The typical use in standard Forth is to throw an integer, although I
> have also seen a case (IIRC in Open Firmware) where the address of a
> counted string is thrown (and the other end is expected to print this).
>
> The benefit of the C++/Java method is that the object can contain
> additional data that can be extracted by the catcher and the catcher
> can make use of the data (e.g., which address was accessed in case of
> a "invalid memory address" exception). Also, the classes form a
> hierarchy, so one catcher can catch a number of related exceptions by
> catching the superclass, while another catcher can catch some more
> specific stuff.
>
> However, given my typical use of CATCH, how often is this additional
> functionality really needed in C++ or Java?
>

Stroustrup discusses this in his book, but I should review it before
commenting. I think it is certainly useful to be able to CATCH
additional information about the throw. THROW restores the stack pointer
value prior to the xt being tried, and before placing the throw code
onto the stack. Other than having a predictable number of items on the
stack after the THROW, there is no useful information about the error
condition contained on the stack other than the throw code.

Of course the Forth programmer can emulate C a la "errno" and place
additional information in variables/structures, but I expect this is
problematic for parallel processing.

-- Krishna

Re: Exception Handling in Standard Forth

<sqveb5$b3k$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16086&group=comp.lang.forth#16086

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Mon, 3 Jan 2022 12:12:51 -0600
Organization: A noiseless patient Spider
Lines: 166
Message-ID: <sqveb5$b3k$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 3 Jan 2022 18:12:53 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="966ba64ce74c6c7fffb6f780c76dae67";
logging-data="11380"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18KHkClNr87B7fWP/m0aMqe"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.2.0
Cancel-Lock: sha1:7ioEttMzXdGg7dsDh5WOL5VClOg=
In-Reply-To: <sqn9tt$fq2$1@dont-email.me>
Content-Language: en-US
 by: Krishna Myneni - Mon, 3 Jan 2022 18:12 UTC

On 12/31/21 10:08, Krishna Myneni wrote:
> Below is a bit of explication on the topic of exception handling in
> Standard Forth, which some readers here may find useful. Quotations (in
> coding) have a useful application to exception handling, and I give an
> example below. To paraphrase Yoda,
>
> "[In Forth], there is no TRY, only CATCH."
>
> Within a definition, the typical way in which exceptions may be caught
> for error handling is to use the following sequence.
>
>    ['] WORDTOTRY CATCH ?DUP IF ... THEN
>
> where WORDTOTRY is the name of the word which will be "TRYed" by CATCH.
> The exception/error handler, in case of a THROW performed anywhere
> within WORDTOTRY, is the code following CATCH, within the IF ... THEN
> block. In the example above, the throw code (exception number) is
> available on the stack for use by the error handler code within the IF
> ... THEN block.
>
....
> My example of CATCH and THROW to handle exceptions from more than one
> word is listed below. The application is for a user interface to a menu
> of functions, each of which is represented by a single key command, e.g.
> 'Q' for Quit. If the user presses a key not corresponding to a menu
> selection, an error is thrown. Also, some menu selections may not always
> be available during execution -- when this occurs, choosing the
> unavailable selection also causes an error to be thrown. The word
> GET-PERFORM is used for obtaining a valid and available menu selection
> and then performing it.
>
> Note the use of CATCH within the definition of RETRY. Also not the use
> of a quotation within the definition of GET-PERFORM.
>
....
>
> \ Notice: Google Groups will destroy the formatting, so apply your
> \ desired punctuation.
>
> : retry ( i*x xt -- j*x )
>     >r
>     BEGIN
>       r@ catch dup
>     WHILE
>       case
>         1 of ." Invalid Selection" endof
>         2 of ." Function Not Available" endof
>       endcase
>       cr
>     REPEAT
>     drop r> drop
> ;
>
> : MenuCommands s" LR123ECHTXQ" ;
>
> : valid? ( c -- c )
>     dup MenuCommands rot scan nip 0= if 1 throw then ;
>
> : available? ( c -- c )
>     dup dup [char] T = swap [char] X = or
>     if 2 throw then ;
>
> : get-perform ( -- )
>     [: key valid? available? ;] retry
>     ." Performing " emit cr
> ;
>
> cr
> .( Select a menu function: ) MenuCommands type cr
> get-perform
>
>

Yet another example of exception/error handling involves a non-standard
word which has often been used in examples presented here. This word is
SLURP-FILE which is found in Gforth. Below is a standard implementation
of SLURP-FILE which uses THROW for the various possible errors. Beware
that I have only partially tested the various error conditions.

-- Krishna

----------
\ slurp-file.4th
\ \ Read the contents of a file into a memory buffer.
\ similar to Gforth's SLURP-FILE
\ \ SLURP-FILE ( c-addr1 u1 -- c-addr2 u2 )
\ \ c-addr1 u1 is the filename string and c-addr2 u2 is the
\ buffer address and size upon success. Errors in SLURP-FILE
\ are thrown for external handling using CATCH. The following
\ throw codes may occur:
\ \ -73 -70 -69 -66 -62 -59 1 2
\ \ Program-defined error codes are 1 and 2, file too large,
\ and slurp size does not match requested read size. The
\ value MAX_SLURP may be adjusted below for use with your
\ system.
\ \ In addition to CATCHing thrown errors, it is up to the
\ user to free the allocated buffer into which the file
\ contents are written, when the buffer is no longer needed.
\ \
\ Example:
\ \ s" m41_inverted_2.png" slurp-file
\ ok
\ .s
\ \ 1610282
\ addr 140100436811792
\ ok
\ over 16 dump ( reformatted output below )
\ \ 7F6BACC4E010 : 89 50 4E 47 0D 0A 1A 0A
\ 00 00 00 0D 49 48 44 52
\ .PNG........IHDR ok
\ \ swap free 2drop
\ ok

\ For kForth
include ans-words
include strings
include files
include dump

1024 1024 * 64 * value MAX_SLURP \ 64 MB limit

0 ptr slurp_buf
variable slurp_fid
variable slurp_size

: slurp-file ( c-addr1 u1 -- c-addr2 u2)
0 slurp_size !
R/O BIN open-file
if -69 throw
then dup slurp_fid !
file-size
if -66 throw
then
0<> over MAX_SLURP > or
if 1 throw \ File too large
then dup slurp_size ! allocate
if -59 throw
then to slurp_buf
0 s>d slurp_fid @ reposition-file
if -73 throw
then slurp_buf slurp_size @ slurp_fid @ read-file
if -70 throw
then slurp_size @ over <>
if 2 throw \ Slurp size and read size do not match
then slurp_buf swap
slurp_fid @ close-file
if -62 throw
then ;
-----------

Re: Exception Handling in Standard Forth

<sr1lcc$1js$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16114&group=comp.lang.forth#16114

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Tue, 4 Jan 2022 08:25:14 -0600
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <sr1lcc$1js$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me>
<2022Jan3.143913@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 4 Jan 2022 14:25:16 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c6508ab722c0fbe68185fca7286c49e0";
logging-data="1660"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ucaY9HFyYvZx1FhdjDsPA"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.2.0
Cancel-Lock: sha1:G9zDvLapQje6IeHs2XtsIJAwets=
In-Reply-To: <2022Jan3.143913@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Krishna Myneni - Tue, 4 Jan 2022 14:25 UTC

On 1/3/22 07:39, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> Within a definition, the typical way in which exceptions may be caught
>> for error handling is to use the following sequence.
>>
>> ['] WORDTOTRY CATCH ?DUP IF ... THEN
>
> My typical usage of CATCH is for cleaning up, and it follows the
> scheme
>
> save-state [: change-state do-something ;] catch restore-state throw
>
> Of course it's also possible that you want to handle a particular
> exception, and then you need to look at the ball instead of just
> throwing it onwards.
>
....

I assume your use of words SAVE-STATE and RESTORE-STATE above goes
beyond just the information CATCH saves within the exception frame
pushed onto the exception/return stack and THROW popping an exception
frame and restoring stack pointers.

The source code implementation of SLURP-FILE which I posted in this
thread illustrates precisely why THROW is not terribly useful by itself
for communicating additional information beyond the throw code. For
example, if SLURP-FILE successfully opens the file, but fails on the
MAX_SLURP test and throws an error code of 1, there is no reliable way
to communicate the file id using only THROW so that the error handler
defined by CATCH can close the file.

With regard to the SLURP-FILE example code, my example input file size
was 1610282 bytes. The relevant code in the SLURP-FILE source is

.... MAX_SLURP > or
if 1 throw \ File too large

If my MAX_SLURP value was set too low, say,

100000 to MAX_SLURP

SLURP-FILE will throw 1 to an error handler set up by CATCH, e.g.

: try-catch [: s" m41_inverted_2.png" slurp-file ;] catch .s ;

The SLURP-FILE code cannot directly communicate the file id, SLURP_FID,
with a throw, e.g.

.... MAX_SLURP > or
if slurp_fid @ 1 THROW ...

When the word TRY-CATCH is run, the slurp buffer is now too small to
acommodate the file size and error 1 will be thrown. The "handler" ( .S)
shows only one argument on the stack, being the throw code 1 and the
slurp_fid value is not on the stack. This is because THROW restores the
stack pointer to the original argument depth for the xt, which, in the
above example, is the stack depth prior to the quotation, before placing
the throw code onto the stack.

The specification for THROW is too restrictive to allow for a
throw-code-dependent argument list on the stack. It may be possible to
define an alternate version of THROW which permits adding a specified
number of additional parameters for a given throw code, e.g.

.... MAX_SLURP > or
if slurp_fid @ 1 1 VTHROW ...

where VTHROW now adjusts the stack pointer to permit one additional
parameter on the stack, which is the file id to be used by the error
handler, for closing the file. If, for this error, we also want to
communicate the actual file size to the error handler, assume it was
locally saved in a 2VARIABLE fsize, and then the throw may be coded as

.... MAX_SLURP > or
if fsize 2@ slurp_fid @ 3 1 VTHROW ...

Note that 1 is the throw code for VTHROW and 3 is the number of
arguments on the stack, beyond the original stack depth. Such a throw
communicates both the file id (for closing the file), and the actual
file size to the error handler, so that the slurp buffer size may be
adjusted and SLURP-FILE tried again.

--
Krishna

Re: Exception Handling in Standard Forth

<7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16147&group=comp.lang.forth#16147

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ad4:5cef:: with SMTP id iv15mr52202474qvb.82.1641433520577;
Wed, 05 Jan 2022 17:45:20 -0800 (PST)
X-Received: by 2002:a37:78b:: with SMTP id 133mr37649382qkh.99.1641433520351;
Wed, 05 Jan 2022 17:45:20 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 5 Jan 2022 17:45:20 -0800 (PST)
In-Reply-To: <sqveb5$b3k$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=86.187.169.61; posting-account=9A5f7goAAAD_QfJPZnlK3Xq_UhzYjdP-
NNTP-Posting-Host: 86.187.169.61
References: <sqn9tt$fq2$1@dont-email.me> <sqveb5$b3k$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com>
Subject: Re: Exception Handling in Standard Forth
From: november...@gmail.com (NN)
Injection-Date: Thu, 06 Jan 2022 01:45:20 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 176
 by: NN - Thu, 6 Jan 2022 01:45 UTC

On Monday, 3 January 2022 at 18:12:55 UTC, Krishna Myneni wrote:
> On 12/31/21 10:08, Krishna Myneni wrote:
> > Below is a bit of explication on the topic of exception handling in
> > Standard Forth, which some readers here may find useful. Quotations (in
> > coding) have a useful application to exception handling, and I give an
> > example below. To paraphrase Yoda,
> >
> > "[In Forth], there is no TRY, only CATCH."
> >
> > Within a definition, the typical way in which exceptions may be caught
> > for error handling is to use the following sequence.
> >
> > ['] WORDTOTRY CATCH ?DUP IF ... THEN
> >
> > where WORDTOTRY is the name of the word which will be "TRYed" by CATCH.
> > The exception/error handler, in case of a THROW performed anywhere
> > within WORDTOTRY, is the code following CATCH, within the IF ... THEN
> > block. In the example above, the throw code (exception number) is
> > available on the stack for use by the error handler code within the IF
> > ... THEN block.
> >
> ...
> > My example of CATCH and THROW to handle exceptions from more than one
> > word is listed below. The application is for a user interface to a menu
> > of functions, each of which is represented by a single key command, e.g.
> > 'Q' for Quit. If the user presses a key not corresponding to a menu
> > selection, an error is thrown. Also, some menu selections may not always
> > be available during execution -- when this occurs, choosing the
> > unavailable selection also causes an error to be thrown. The word
> > GET-PERFORM is used for obtaining a valid and available menu selection
> > and then performing it.
> >
> > Note the use of CATCH within the definition of RETRY. Also not the use
> > of a quotation within the definition of GET-PERFORM.
> >
> ...
> >
> > \ Notice: Google Groups will destroy the formatting, so apply your
> > \ desired punctuation.
> >
> > : retry ( i*x xt -- j*x )
> > >r
> > BEGIN
> > r@ catch dup
> > WHILE
> > case
> > 1 of ." Invalid Selection" endof
> > 2 of ." Function Not Available" endof
> > endcase
> > cr
> > REPEAT
> > drop r> drop
> > ;
> >
> > : MenuCommands s" LR123ECHTXQ" ;
> >
> > : valid? ( c -- c )
> > dup MenuCommands rot scan nip 0= if 1 throw then ;
> >
> > : available? ( c -- c )
> > dup dup [char] T = swap [char] X = or
> > if 2 throw then ;
> >
> > : get-perform ( -- )
> > [: key valid? available? ;] retry
> > ." Performing " emit cr
> > ;
> >
> > cr
> > .( Select a menu function: ) MenuCommands type cr
> > get-perform
> >
> >
> Yet another example of exception/error handling involves a non-standard
> word which has often been used in examples presented here. This word is
> SLURP-FILE which is found in Gforth. Below is a standard implementation
> of SLURP-FILE which uses THROW for the various possible errors. Beware
> that I have only partially tested the various error conditions.
>
> -- Krishna
>
>
> ----------
> \ slurp-file.4th
> \
> \ Read the contents of a file into a memory buffer.
> \ similar to Gforth's SLURP-FILE
> \
> \ SLURP-FILE ( c-addr1 u1 -- c-addr2 u2 )
> \
> \ c-addr1 u1 is the filename string and c-addr2 u2 is the
> \ buffer address and size upon success. Errors in SLURP-FILE
> \ are thrown for external handling using CATCH. The following
> \ throw codes may occur:
> \
> \ -73 -70 -69 -66 -62 -59 1 2
> \
> \ Program-defined error codes are 1 and 2, file too large,
> \ and slurp size does not match requested read size. The
> \ value MAX_SLURP may be adjusted below for use with your
> \ system.
> \
> \ In addition to CATCHing thrown errors, it is up to the
> \ user to free the allocated buffer into which the file
> \ contents are written, when the buffer is no longer needed.
> \
> \
> \ Example:
> \
> \ s" m41_inverted_2.png" slurp-file
> \ ok
> \ .s
> \
> \ 1610282
> \ addr 140100436811792
> \ ok
> \ over 16 dump ( reformatted output below )
> \
> \ 7F6BACC4E010 : 89 50 4E 47 0D 0A 1A 0A
> \ 00 00 00 0D 49 48 44 52
> \ .PNG........IHDR ok
> \
> \ swap free 2drop
> \ ok
>
>
> \ For kForth
> include ans-words
> include strings
> include files
> include dump
>
> 1024 1024 * 64 * value MAX_SLURP \ 64 MB limit
>
> 0 ptr slurp_buf
> variable slurp_fid
> variable slurp_size
>
> : slurp-file ( c-addr1 u1 -- c-addr2 u2)
> 0 slurp_size !
> R/O BIN open-file
> if -69 throw
> then dup slurp_fid !
> file-size
> if -66 throw
> then
> 0<> over MAX_SLURP > or
> if 1 throw \ File too large
> then dup slurp_size ! allocate
> if -59 throw
> then to slurp_buf
> 0 s>d slurp_fid @ reposition-file
> if -73 throw
> then slurp_buf slurp_size @ slurp_fid @ read-file
> if -70 throw
> then slurp_size @ over <>
> if 2 throw \ Slurp size and read size do not match
> then slurp_buf swap
> slurp_fid @ close-file
> if -62 throw
> then ;
> -----------

I thought if you implemented the file extention wordset
then if that particular word failed it would throw the standard 'throws'.

Looking at the above slurp-file, is this just for kforth that you need to
throw the right 'throws' should that word fail. ie the word might return
a kforth internal 'ior'

I tried looking up gforth slurp-file but all i found was ...
https://gforth.org/manual/General-files.html
which doesnt tell me much.

It appears to be reading a file to memory. Is that all ? or is there more
happenning I dont understand.

Re: Exception Handling in Standard Forth

<sr71lj$vf4$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16168&group=comp.lang.forth#16168

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Thu, 6 Jan 2022 09:25:37 -0600
Organization: A noiseless patient Spider
Lines: 143
Message-ID: <sr71lj$vf4$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me> <sqveb5$b3k$1@dont-email.me>
<7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 6 Jan 2022 15:25:39 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a2a3b05a35b31192e8a04fb0ffa061d5";
logging-data="32228"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1822xLE0BNa7CX+Xox3HZNf"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.2.0
Cancel-Lock: sha1:7jw087h4EYUjYQ6hEb09klQ3dKY=
In-Reply-To: <7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com>
Content-Language: en-US
 by: Krishna Myneni - Thu, 6 Jan 2022 15:25 UTC

On 1/5/22 19:45, NN wrote:
> On Monday, 3 January 2022 at 18:12:55 UTC, Krishna Myneni wrote:
....
>> Yet another example of exception/error handling involves a non-standard
>> word which has often been used in examples presented here. This word is
>> SLURP-FILE which is found in Gforth. Below is a standard implementation
>> of SLURP-FILE which uses THROW for the various possible errors. Beware
>> that I have only partially tested the various error conditions.
>>
>> -- Krishna
>>
>>
>> ----------
>> \ slurp-file.4th
>> \
>> \ Read the contents of a file into a memory buffer.
>> \ similar to Gforth's SLURP-FILE
>> \
>> \ SLURP-FILE ( c-addr1 u1 -- c-addr2 u2 )
>> \
>> \ c-addr1 u1 is the filename string and c-addr2 u2 is the
>> \ buffer address and size upon success. Errors in SLURP-FILE
>> \ are thrown for external handling using CATCH. The following
>> \ throw codes may occur:
>> \
>> \ -73 -70 -69 -66 -62 -59 1 2
>> \
>> \ Program-defined error codes are 1 and 2, file too large,
>> \ and slurp size does not match requested read size. The
>> \ value MAX_SLURP may be adjusted below for use with your
>> \ system.
>> \
>> \ In addition to CATCHing thrown errors, it is up to the
>> \ user to free the allocated buffer into which the file
>> \ contents are written, when the buffer is no longer needed.
>> \
>> \
>> \ Example:
>> \
>> \ s" m41_inverted_2.png" slurp-file
>> \ ok
>> \ .s
>> \
>> \ 1610282
>> \ addr 140100436811792
>> \ ok
>> \ over 16 dump ( reformatted output below )
>> \
>> \ 7F6BACC4E010 : 89 50 4E 47 0D 0A 1A 0A
>> \ 00 00 00 0D 49 48 44 52
>> \ .PNG........IHDR ok
>> \
>> \ swap free 2drop
>> \ ok
>>
>>
>> \ For kForth
>> include ans-words
>> include strings
>> include files
>> include dump
>>
>> 1024 1024 * 64 * value MAX_SLURP \ 64 MB limit
>>
>> 0 ptr slurp_buf
>> variable slurp_fid
>> variable slurp_size
>>
>> : slurp-file ( c-addr1 u1 -- c-addr2 u2)
>> 0 slurp_size !
>> R/O BIN open-file
>> if -69 throw
>> then dup slurp_fid !
>> file-size
>> if -66 throw
>> then
>> 0<> over MAX_SLURP > or
>> if 1 throw \ File too large
>> then dup slurp_size ! allocate
>> if -59 throw
>> then to slurp_buf
>> 0 s>d slurp_fid @ reposition-file
>> if -73 throw
>> then slurp_buf slurp_size @ slurp_fid @ read-file
>> if -70 throw
>> then slurp_size @ over <>
>> if 2 throw \ Slurp size and read size do not match
>> then slurp_buf swap
>> slurp_fid @ close-file
>> if -62 throw
>> then ;
>> -----------
>
>
> I thought if you implemented the file extention wordset
> then if that particular word failed it would throw the standard 'throws'.
>
Per the Forth-2012 standard, which I believe hasn't changed w.r.t. the
Forth-94 standard with regard to the File Access wordset, the file
access words return a ior code, for which zero indicates success, and
for which nonzero is an implementation-defined result indicating
failure. This is certainly true for OPEN-FILE, FILE-SIZE, and READ-FILE.
These words are not required to THROW an error upon failure.

For REPOSITION-FILE, the standard states an ambiguous condition if it
attempts to reposition the file outside of its boundaries; however, 0
s>d is a valid file position, so it is expected that ior being zero
indicates that the operation succeeded (although the standard does not
explicitly state this).

For CLOSE-FILE, the standard is also not specific about the value of ior
on success; however, I think most systems return zero on success.

> Looking at the above slurp-file, is this just for kforth that you need to
> throw the right 'throws' should that word fail. ie the word might return
> a kforth internal 'ior'
>

The implementation of SLURP-FILE is generic, except for the include
files needed to use it under kForth. The throw codes for the file access
words are standard in Forth-94 and in Forth-2012 (see Table 9.1) in the
Forth 2012 standard document. The throw codes 1 and 2 are program-specific.

> I tried looking up gforth slurp-file but all i found was ...
> https://gforth.org/manual/General-files.html
> which doesnt tell me much.
>
> It appears to be reading a file to memory. Is that all ? or is there more
> happenning I dont understand.
>

Yes, the word SLURP-FILE is used to bring the file contents into memory.
I use the implementation above to illustrate the limitations of THROW,
which can only reliably communicate the throw code on the stack to an
error handler. Thus, for example, if we want to allow for the
possibility of an error handler closing the file or to readjust the
maximum amount of memory for SLURP-FILE in case the file size exceeds
MAX_SLURP, standard THROW is unable to communicate the required
information on the stack to the error handler.

--
Krishna

Re: Exception Handling in Standard Forth

<sr7ak5$5v6$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16172&group=comp.lang.forth#16172

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: do-not-...@swldwa.uk (Gerry Jackson)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Thu, 6 Jan 2022 17:58:32 +0000
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <sr7ak5$5v6$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me> <sqveb5$b3k$1@dont-email.me>
<7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com>
<sr71lj$vf4$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 6 Jan 2022 17:58:29 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ed05adff42d6b044c5ad791f1b70aab4";
logging-data="6118"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+t45e0Xg28l+Fr4wZMjZuz/Xuf+IYlA9Q="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Cancel-Lock: sha1:6lX6P2S4wQ0yvCx9/oVrOgCPKrs=
In-Reply-To: <sr71lj$vf4$1@dont-email.me>
 by: Gerry Jackson - Thu, 6 Jan 2022 17:58 UTC

On 06/01/2022 15:25, Krishna Myneni wrote:
> On 1/5/22 19:45, NN wrote:

>> I thought if you implemented the file extention wordset
>> then if that particular word failed it would throw the standard 'throws'.
>>
> Per the Forth-2012 standard, which I believe hasn't changed w.r.t. the
> Forth-94 standard with regard to the File Access wordset, the file
> access words return a ior code, for which zero indicates success, and
> for which nonzero is an implementation-defined result indicating
> failure. This is certainly true for OPEN-FILE, FILE-SIZE, and READ-FILE.
> These words are not required to THROW an error upon failure.

Table 9.1 in the Forth 2012 standard extended the ANS table to include
THROW codes for most if not all words in the file wordset and 9.3.4 states:

"A system choosing to execute THROW when detecting one of the ambiguous
conditions listed in table 9.1 shall use the throw code listed there."

This disagrees with the specifications for the file words. I would think
that when the table was updated the individual specifications weren't
updated at the same time and the ior values should not be implementation
defined. Perhaps I'm wrong in which case 9.3.4 needs correcting.

Perhaps a committee member could comment/rule on the matter

--
Gerry

Re: Exception Handling in Standard Forth

<sr7bpq$etr$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16173&group=comp.lang.forth#16173

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Thu, 6 Jan 2022 12:18:32 -0600
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <sr7bpq$etr$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me> <sqveb5$b3k$1@dont-email.me>
<7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com>
<sr71lj$vf4$1@dont-email.me> <sr7ak5$5v6$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 6 Jan 2022 18:18:34 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a2a3b05a35b31192e8a04fb0ffa061d5";
logging-data="15291"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+d9makPcuDKtKOJWQc+NOm"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.2.0
Cancel-Lock: sha1:E7q+dx9HeI22scsdPQYC3s3joHw=
In-Reply-To: <sr7ak5$5v6$1@dont-email.me>
Content-Language: en-US
 by: Krishna Myneni - Thu, 6 Jan 2022 18:18 UTC

On 1/6/22 11:58, Gerry Jackson wrote:
> On 06/01/2022 15:25, Krishna Myneni wrote:
>> On 1/5/22 19:45, NN wrote:
>
>>> I thought if you implemented the file extention wordset
>>> then if that particular word failed it would throw the standard
>>> 'throws'.
>>>
>> Per the Forth-2012 standard, which I believe hasn't changed w.r.t. the
>> Forth-94 standard with regard to the File Access wordset, the file
>> access words return a ior code, for which zero indicates success, and
>> for which nonzero is an implementation-defined result indicating
>> failure. This is certainly true for OPEN-FILE, FILE-SIZE, and
>> READ-FILE. These words are not required to THROW an error upon failure.
>
> Table 9.1 in the Forth 2012 standard extended the ANS table to include
> THROW codes for most if not all words in the file wordset and 9.3.4 states:
>
> "A system choosing to execute THROW when detecting one of the ambiguous
> conditions listed in table 9.1 shall use the throw code listed there."
>

Why would a system presume to execute a THROW when the programmer can
examine the ior and choose to execute a THROW or do something different,
such as handle the error at that point in the code? I expect the ior
result in case of failure could contain more information about the type
of failure. The above statement does not make much sense to me.

--
Krishna

Re: Exception Handling in Standard Forth

<2022Jan7.000258@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16177&group=comp.lang.forth#16177

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Thu, 06 Jan 2022 23:02:58 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 44
Message-ID: <2022Jan7.000258@mips.complang.tuwien.ac.at>
References: <sqn9tt$fq2$1@dont-email.me> <sqveb5$b3k$1@dont-email.me> <7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com> <sr71lj$vf4$1@dont-email.me> <sr7ak5$5v6$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="266a68bc2adbdc07b9125a6ea0f8acea";
logging-data="15670"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18nF48gnIjiiTtmYBhfwCLl"
Cancel-Lock: sha1:t0updO1YgLCC1nPlFo6db1LZhCU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Thu, 6 Jan 2022 23:02 UTC

Gerry Jackson <do-not-use@swldwa.uk> writes:
>Table 9.1 in the Forth 2012 standard extended the ANS table to include
>THROW codes for most if not all words in the file wordset

Apart form -77, the new THROW codes (those <-58) in Forth-2012 just
name words that produce an ior. They seem pretty pointless to me and
are not in the spirit of the Forth-94 throw codes.

>and 9.3.4 states:
>
>"A system choosing to execute THROW when detecting one of the ambiguous
>conditions listed in table 9.1 shall use the throw code listed there."

That's badly written, because Table 9.1 contains throw codes, not
ambiguous conditions. In some cases the throw codes correspond to
ambiguous conditons, e.g., -10 (Division by zero); it corresponds to
the sentencin in the specification of /:

| An ambiguous condition exists if n2 is zero.

So I guess that this sentence expresses that if a standard system
THROWS on division by zero, it must throw -10.

For the conditions reported through iors, those are not ambiguous
conditions and are not THROWn by the system (but typically by an
explicit THROW after the word producing the ior).

>This disagrees with the specifications for the file words. I would think
>that when the table was updated the individual specifications weren't
>updated at the same time and the ior values should not be implementation
>defined.

I think we tried at some point to make it clear that iors can be
thrown. I think the additional values in Table 9.1 are a wrong-headed
attempt at realizing that idea. I think we had another go at it, but
at the moment I don't know (and am too tired to look up) if that went
anywhere.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Exception Handling in Standard Forth

<sr8p7o$334$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16180&group=comp.lang.forth#16180

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: do-not-...@swldwa.uk (Gerry Jackson)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Fri, 7 Jan 2022 07:13:59 +0000
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <sr8p7o$334$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me> <sqveb5$b3k$1@dont-email.me>
<7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com>
<sr71lj$vf4$1@dont-email.me> <sr7ak5$5v6$1@dont-email.me>
<sr7bpq$etr$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 7 Jan 2022 07:14:00 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f7bd62bdcbee4c0aaf851dab6c83b6de";
logging-data="3172"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198dL75/TMHm0oNVDJhHpkUtzv0kDCI//g="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Cancel-Lock: sha1:KiwihknMh3/nye+DdFwiKAdsVLs=
In-Reply-To: <sr7bpq$etr$1@dont-email.me>
 by: Gerry Jackson - Fri, 7 Jan 2022 07:13 UTC

On 06/01/2022 18:18, Krishna Myneni wrote:
> On 1/6/22 11:58, Gerry Jackson wrote:
>> On 06/01/2022 15:25, Krishna Myneni wrote:
>>> On 1/5/22 19:45, NN wrote:
>>
>>>> I thought if you implemented the file extention wordset
>>>> then if that particular word failed it would throw the standard
>>>> 'throws'.
>>>>
>>> Per the Forth-2012 standard, which I believe hasn't changed w.r.t.
>>> the Forth-94 standard with regard to the File Access wordset, the
>>> file access words return a ior code, for which zero indicates
>>> success, and for which nonzero is an implementation-defined result
>>> indicating failure. This is certainly true for OPEN-FILE, FILE-SIZE,
>>> and READ-FILE. These words are not required to THROW an error upon
>>> failure.
>>
>> Table 9.1 in the Forth 2012 standard extended the ANS table to include
>> THROW codes for most if not all words in the file wordset and 9.3.4
>> states:
>>
>> "A system choosing to execute THROW when detecting one of the
>> ambiguous conditions listed in table 9.1 shall use the throw code
>> listed there."
>>
>
> Why would a system presume to execute a THROW when the programmer can
> examine the ior and choose to execute a THROW or do something different,
> such as handle the error at that point in the code? I expect the ior
> result in case of failure could contain more information about the type
> of failure. The above statement does not make much sense to me.
>
>
> --
> Krishna

I thought you were right when I looked at the ANS Forth standard where
section 11.3.1.2 I/O results, second paragraph reads:

"An I/O exception in the execution of a File-Access word that can return
an I/O result shall not cause a THROW; exception indications are
returned in the ior"

But the online Forth 2012 standard has removed section 11.3.1.2
entirely. As Anton Ertl confirms in another response to you, it all
seems a bit of a mess.

--
Gerry

Re: Exception Handling in Standard Forth

<2022Jan7.100825@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16181&group=comp.lang.forth#16181

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Fri, 07 Jan 2022 09:08:25 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 22
Message-ID: <2022Jan7.100825@mips.complang.tuwien.ac.at>
References: <sqn9tt$fq2$1@dont-email.me> <sqveb5$b3k$1@dont-email.me> <7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com> <sr71lj$vf4$1@dont-email.me> <sr7ak5$5v6$1@dont-email.me> <sr7bpq$etr$1@dont-email.me> <sr8p7o$334$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="266a68bc2adbdc07b9125a6ea0f8acea";
logging-data="23114"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rc53Fhzq0iTQ+F4bXVdqo"
Cancel-Lock: sha1:Azm9xTKr57jIkp0dNLDaHjk2PTI=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Fri, 7 Jan 2022 09:08 UTC

Gerry Jackson <do-not-use@swldwa.uk> writes:
>I thought you were right when I looked at the ANS Forth standard where
>section 11.3.1.2 I/O results, second paragraph reads:
>
>"An I/O exception in the execution of a File-Access word that can return
>an I/O result shall not cause a THROW; exception indications are
>returned in the ior"
>
>But the online Forth 2012 standard has removed section 11.3.1.2
>entirely.

It was removed from Chapter 11 when we moved ior from Table 11.1 to
table 3.1 (because already in Forth-94 ior was not limited to the
File-Access wordset). The corresponding section in Chapter 3 is
3.1.3.6.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Exception Handling in Standard Forth

<2022Jan7.103920@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16182&group=comp.lang.forth#16182

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Fri, 07 Jan 2022 09:39:20 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 15
Message-ID: <2022Jan7.103920@mips.complang.tuwien.ac.at>
References: <sqn9tt$fq2$1@dont-email.me> <sqveb5$b3k$1@dont-email.me> <7bd23335-dfb2-4565-9cad-8a70a33167d1n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="266a68bc2adbdc07b9125a6ea0f8acea";
logging-data="23114"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/YQ99AC5as9/SrEOTsfFPl"
Cancel-Lock: sha1:T+F/Wfh5BwI/KTmGnoYHz3ZxQd0=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Fri, 7 Jan 2022 09:39 UTC

NN <november.nihal@gmail.com> writes:
>I tried looking up gforth slurp-file but all i found was ...
>https://gforth.org/manual/General-files.html
>which doesnt tell me much.
>
>It appears to be reading a file to memory. Is that all ?

Yes.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Exception Handling in Standard Forth

<2022Jan8.190233@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16219&group=comp.lang.forth#16219

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Sat, 08 Jan 2022 18:02:33 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 13
Message-ID: <2022Jan8.190233@mips.complang.tuwien.ac.at>
References: <sqn9tt$fq2$1@dont-email.me> <2022Jan3.143913@mips.complang.tuwien.ac.at> <sqve1k$5ii$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="eca042e37b89111e037ca1e8c61dc68a";
logging-data="7954"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/yHuEcIVRA3E+Wf97ZPFYs"
Cancel-Lock: sha1:5wFcKQLq+QPVczbqUySeoqmQQvU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 8 Jan 2022 18:02 UTC

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>Of course the Forth programmer can emulate C a la "errno" and place
>additional information in variables/structures, but I expect this is
>problematic for parallel processing.

Just like C, use thread-local storage, i.e., a user variable.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Exception Handling in Standard Forth

<2022Jan8.192746@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16222&group=comp.lang.forth#16222

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Sat, 08 Jan 2022 18:27:46 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 86
Message-ID: <2022Jan8.192746@mips.complang.tuwien.ac.at>
References: <sqn9tt$fq2$1@dont-email.me> <2022Jan3.143913@mips.complang.tuwien.ac.at> <sr1lcc$1js$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="eca042e37b89111e037ca1e8c61dc68a";
logging-data="7954"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18uLTjKEh54eWPllAcHfeab"
Cancel-Lock: sha1:khm61n8nzYk7CHKi2v1BB96y8+I=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 8 Jan 2022 18:27 UTC

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On 1/3/22 07:39, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> Within a definition, the typical way in which exceptions may be caught
>>> for error handling is to use the following sequence.
>>>
>>> ['] WORDTOTRY CATCH ?DUP IF ... THEN
>>
>> My typical usage of CATCH is for cleaning up, and it follows the
>> scheme
>>
>> save-state [: change-state do-something ;] catch restore-state throw
>>
>> Of course it's also possible that you want to handle a particular
>> exception, and then you need to look at the ball instead of just
>> throwing it onwards.
>>
>...
>
>I assume your use of words SAVE-STATE and RESTORE-STATE above goes
>beyond just the information CATCH saves within the exception frame
>pushed onto the exception/return stack and THROW popping an exception
>frame and restoring stack pointers.

Yes, of course. This pattern is there exactly for making sure that
state is restored that CATCH does not restore by itself. A more
concrete example:

: hex. ( u -- )
base @ >r [: hex u. ;] catch r> base ! throw ;

>The source code implementation of SLURP-FILE which I posted in this
>thread illustrates precisely why THROW is not terribly useful by itself
>for communicating additional information beyond the throw code. For
>example, if SLURP-FILE successfully opens the file, but fails on the
>MAX_SLURP test and throws an error code of 1, there is no reliable way
>to communicate the file id using only THROW so that the error handler
>defined by CATCH can close the file.

The way to do that would be to write slurp-file as

: slurp-file
... open-file throw dup >r [: ... ;] catch r> close-file throw throw ;

That eliminates the need to communicate the file-id further out and
let some far-out catch deal with all sorts of trouble that that
handler is probably badly prepared to deal with.

If you want to be safe against an exception between the start of CATCH
and the end of CLOSE-FILE, Gforth has a more refined construct
try...restore...endtry that is slightly safer against that (there is
still the risk that an exception in a half-finished CLOSE-FILE leaves
the file in a corrupted state, so rerunning CLOSE-FILE may not work as
intended.

>The specification for THROW is too restrictive to allow for a
>throw-code-dependent argument list on the stack. It may be possible to
>define an alternate version of THROW which permits adding a specified
>number of additional parameters for a given throw code, e.g.
>
>... MAX_SLURP > or
>if slurp_fid @ 1 1 VTHROW ...
>
>where VTHROW now adjusts the stack pointer to permit one additional
>parameter on the stack, which is the file id to be used by the error
>handler, for closing the file. If, for this error, we also want to
>communicate the actual file size to the error handler, assume it was
>locally saved in a 2VARIABLE fsize, and then the throw may be coded as
>
>... MAX_SLURP > or
>if fsize 2@ slurp_fid @ 3 1 VTHROW ...
>
>Note that 1 is the throw code for VTHROW and 3 is the number of
>arguments on the stack, beyond the original stack depth.

If I ever need to go there, the idea of passing additional data
through a variable-stack-effect VTHROW looks in line with stuff like
SET-ORDER, but I hope I never have to go there. And given that I have
not needed to in the last 30 years, I think my chances are good.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Exception Handling in Standard Forth

<srd7vd$pdk$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16226&group=comp.lang.forth#16226

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Sun, 9 Jan 2022 02:50:04 +0300
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <srd7vd$pdk$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me>
<2022Jan3.143913@mips.complang.tuwien.ac.at> <sqve1k$5ii$1@dont-email.me>
<2022Jan8.190233@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 8 Jan 2022 23:50:05 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a1e483578fadd794e83c005dcdb874b6";
logging-data="26036"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/IzA4Qrvsb7vBm9XVXZynB"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Cancel-Lock: sha1:d6OT8Jg5U2z6PjJr7pa2RvdXa+A=
In-Reply-To: <2022Jan8.190233@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Ruvim - Sat, 8 Jan 2022 23:50 UTC

On 2022-01-08 21:02, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> Of course the Forth programmer can emulate C a la "errno" and place
>> additional information in variables/structures, but I expect this is
>> problematic for parallel processing.
>
> Just like C, use thread-local storage, i.e., a user variable.

Another problem is undesired overwriting.

An example (a pattern):

: foo
[: do-bar ;] catch >r
[: finish-bar ;] catch
r> throw throw
;

In this example we re-throw an exception from do-bar after finish-bar.
But if an exception also occurs in finish-bar, "errno" can be
overwritten, and then incorrect information will be passed upward.

So some API is required to save and restore (or nest) such errno.
Probably, the above pattern will be also changed according to the API.

--
Ruvim

Re: Exception Handling in Standard Forth

<2022Jan9.185057@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16238&group=comp.lang.forth#16238

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Sun, 09 Jan 2022 17:50:57 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 60
Message-ID: <2022Jan9.185057@mips.complang.tuwien.ac.at>
References: <sqn9tt$fq2$1@dont-email.me> <2022Jan3.143913@mips.complang.tuwien.ac.at> <sqve1k$5ii$1@dont-email.me> <2022Jan8.190233@mips.complang.tuwien.ac.at> <srd7vd$pdk$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="ac1f63466b2b9994d280e680ff22633d";
logging-data="7913"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/K+qvVEfIPzSgq6V8yspr7"
Cancel-Lock: sha1:rUZ5GWX6FKsTdpw1zzZp2edzPJw=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sun, 9 Jan 2022 17:50 UTC

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2022-01-08 21:02, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> Of course the Forth programmer can emulate C a la "errno" and place
>>> additional information in variables/structures, but I expect this is
>>> problematic for parallel processing.
>>
>> Just like C, use thread-local storage, i.e., a user variable.
>
>Another problem is undesired overwriting.
>
>An example (a pattern):
>
> : foo
> [: do-bar ;] catch >r
> [: finish-bar ;] catch
> r> throw throw
> ;
>
>In this example we re-throw an exception from do-bar after finish-bar.

How often have you had this?

>But if an exception also occurs in finish-bar, "errno" can be
>overwritten, and then incorrect information will be passed upward.

So better write this code as:

: foo
[: do-bar ;] catch >r
[: finish-bar ;] catch
throw r> throw
;

Then the "errno" will be the one belonging to the throw ball.

Of course, you may find it unsatisfactory that the ball and errno of
the first exception are ignored. So you may want to have something
like:

: foo
[: do-bar ;] catch errno 2>r
[: finish-bar ;] catch
2r> combine-errors throw
;

where combine-errors checks the two throw codes, and if they are both
non-zero, produces an "errno" (which would be some more complex object
rather than just a number) that contains both throw codes and both
errnos, and produces a throw code that indicates that multiple
exceptions have happened.

But I have yet to encounter the need for such a thing.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Exception Handling in Standard Forth

<srfdet$6bm$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16241&group=comp.lang.forth#16241

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Sun, 9 Jan 2022 22:35:56 +0300
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <srfdet$6bm$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me>
<2022Jan3.143913@mips.complang.tuwien.ac.at> <sqve1k$5ii$1@dont-email.me>
<2022Jan8.190233@mips.complang.tuwien.ac.at> <srd7vd$pdk$1@dont-email.me>
<2022Jan9.185057@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 9 Jan 2022 19:35:58 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a1e483578fadd794e83c005dcdb874b6";
logging-data="6518"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+zj+Hq5ZmVpxXkAIqc56uk"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Cancel-Lock: sha1:f7aBo421WPi2vUTY/tKkxwNPOBU=
In-Reply-To: <2022Jan9.185057@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Ruvim - Sun, 9 Jan 2022 19:35 UTC

On 2022-01-09 20:50, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2022-01-08 21:02, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>> Of course the Forth programmer can emulate C a la "errno" and place
>>>> additional information in variables/structures, but I expect this is
>>>> problematic for parallel processing.
>>>
>>> Just like C, use thread-local storage, i.e., a user variable.
>>
>> Another problem is undesired overwriting.
>>
>> An example (a pattern):
>>
>> : foo
>> [: do-bar ;] catch >r
>> [: finish-bar ;] catch
>> r> throw throw
>> ;
>>
>> In this example we re-throw an exception from do-bar after finish-bar.
>
> How often have you had this?

Almost always I rethrow the earliest exception first in such cases.
For example, see the search results for "THROW THROW" in sp-forth/4
repository: https://git.io/J9GFG (NB: GitHub requires authentication for
this search request due to additional parameters).

>> But if an exception also occurs in finish-bar, "errno" can be
>> overwritten, and then incorrect information will be passed upward.
>
> So better write this code as:
>
> : foo
> [: do-bar ;] catch >r
> [: finish-bar ;] catch
> throw r> throw
> ;
>
> Then the "errno" will be the one belonging to the throw ball.

But the first (earliest) ball is far more preferred then the second.

> Of course, you may find it unsatisfactory that the ball and errno of
> the first exception are ignored. So you may want to have something
> like:
>
> : foo
> [: do-bar ;] catch errno 2>r
> [: finish-bar ;] catch
> 2r> combine-errors throw
> ;
>
> where combine-errors checks the two throw codes, and if they are both
> non-zero, produces an "errno" (which would be some more complex object
> rather than just a number) that contains both throw codes and both
> errnos, and produces a throw code that indicates that multiple
> exceptions have happened.

Yes, by nesting I mean this variant too. In general case it's a list of
error objects (one refers the next one, etc).

>
> But I have yet to encounter the need for such a thing.

Me too.

But in the basic variant I want to throw just the earliest ball (and
it's errno, if any), since log of the initial error is critical for
debugging and investigation of possible problems.

--
Ruvim

Re: Exception Handling in Standard Forth

<srfrus$a1f$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16244&group=comp.lang.forth#16244

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Exception Handling in Standard Forth
Date: Sun, 9 Jan 2022 17:43:22 -0600
Organization: A noiseless patient Spider
Lines: 139
Message-ID: <srfrus$a1f$1@dont-email.me>
References: <sqn9tt$fq2$1@dont-email.me>
<2022Jan3.143913@mips.complang.tuwien.ac.at> <sr1lcc$1js$1@dont-email.me>
<2022Jan8.192746@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 9 Jan 2022 23:43:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="77a1c570c4ca83f60510ab6d1032092d";
logging-data="10287"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+sKZJ4AeV2gb5XzwXNbAqY"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.2.0
Cancel-Lock: sha1:IAmiREt3dARanVY79u8o4cgTxNk=
In-Reply-To: <2022Jan8.192746@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Krishna Myneni - Sun, 9 Jan 2022 23:43 UTC

On 1/8/22 12:27, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> On 1/3/22 07:39, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>> Within a definition, the typical way in which exceptions may be caught
>>>> for error handling is to use the following sequence.
>>>>
>>>> ['] WORDTOTRY CATCH ?DUP IF ... THEN
>>>
>>> My typical usage of CATCH is for cleaning up, and it follows the
>>> scheme
>>>
>>> save-state [: change-state do-something ;] catch restore-state throw
>>>
>>> Of course it's also possible that you want to handle a particular
>>> exception, and then you need to look at the ball instead of just
>>> throwing it onwards.
>>>
>> ...
>>
>> I assume your use of words SAVE-STATE and RESTORE-STATE above goes
>> beyond just the information CATCH saves within the exception frame
>> pushed onto the exception/return stack and THROW popping an exception
>> frame and restoring stack pointers.
>
> Yes, of course. This pattern is there exactly for making sure that
> state is restored that CATCH does not restore by itself. A more
> concrete example:
>
> : hex. ( u -- )
> base @ >r [: hex u. ;] catch r> base ! throw ;
>

Ok, this is a good example. At first I was thinking, why would the code
in the quotation throw an exception, but U. can perform a throw if
nothing is on the stack.

>> The source code implementation of SLURP-FILE which I posted in this
>> thread illustrates precisely why THROW is not terribly useful by itself
>> for communicating additional information beyond the throw code. For
>> example, if SLURP-FILE successfully opens the file, but fails on the
>> MAX_SLURP test and throws an error code of 1, there is no reliable way
>> to communicate the file id using only THROW so that the error handler
>> defined by CATCH can close the file.
>
> The way to do that would be to write slurp-file as
>
> : slurp-file
> ... open-file throw dup >r [: ... ;] catch r> close-file throw throw ;

> That eliminates the need to communicate the file-id further out and
> let some far-out catch deal with all sorts of trouble that that
> handler is probably badly prepared to deal with.
>

If you only want to close the file on an error, yes, that's best done at
the earliest point where the error is detected. Within the SLURP-FILE
example, this would be best done, for example, as

....
file-size
if slurp_fid @ close-file drop -66 throw
then
0<> over MAX_SLURP > or
if slurp_fid @ close-file drop 1 throw \ File too large
then dup slurp_size ! allocate
if slurp_fid @ close-file drop -59 throw
....

However, this still does not allow for us to pass adequate information
for handling throw code 1, when the actual file size is larger than the
initial setting of MAX_SLURP.

Let us assume we have a module (a library with a well-defined interface
along with information private to the library) which includes SLURP-FILE
and SET-MAX-SIZE as interface words. Despite the default setting of the
library, the handler could respond to throw code 1 by looking at the
available memory in the system, at that particular instance, compared to
the file size, and decide whether or not there is enough memory
available to safely increase the max size to accommodate the file. In
such a case, the program can retry to slurp the file; otherwise it can
throw an error farther up the call chain.

Of course there are other ways to organize the program so that checks
are done prior to calling SET-MAX-SIZE and SLURP-FILE, but if this
scenario is an exception (not likely to occur frequently), then an
exception handler equipped to deal with the problem is justified.
Global variables, structures, per thread instances are one way of
communicating extra information to a handler, but should we restrict
THROWs to not being able to pass any information from the place where
the error is detected to the place where the handler may make use of it?

....
>
>> The specification for THROW is too restrictive to allow for a
>> throw-code-dependent argument list on the stack. It may be possible to
>> define an alternate version of THROW which permits adding a specified
>> number of additional parameters for a given throw code, e.g.
>>
>> ... MAX_SLURP > or
>> if slurp_fid @ 1 1 VTHROW ...
>>
>> where VTHROW now adjusts the stack pointer to permit one additional
>> parameter on the stack, which is the file id to be used by the error
>> handler, for closing the file. If, for this error, we also want to
>> communicate the actual file size to the error handler, assume it was
>> locally saved in a 2VARIABLE fsize, and then the throw may be coded as
>>
>> ... MAX_SLURP > or
>> if fsize 2@ slurp_fid @ 3 1 VTHROW ...
>>
>> Note that 1 is the throw code for VTHROW and 3 is the number of
>> arguments on the stack, beyond the original stack depth.
>
> If I ever need to go there, the idea of passing additional data
> through a variable-stack-effect VTHROW looks in line with stuff like
> SET-ORDER, but I hope I never have to go there. And given that I have
> not needed to in the last 30 years, I think my chances are good.
>

A simpler solution might be to define +THROW which communicates two
cells to the handler ( ... -- ... x n ), where n is the throw code and x
can be a number, a structure address, or an object address. In order for
this to work with the existing CATCH, we would have to define a range
for extended throw codes so that the handler knows when x is available
on the stack. Words which can throw such extended information must
document what x is and whether or not, for the case of structures or
objects, the memory associated with x needs to be freed by the handler.

I'm not sure the argument that you haven't needed this in the last 30
years is a good argument to make. The lack of a capability tends to
influence one's style of programming. When the capability is present, it
may lead to a different style. Nevertheless, justification for +THROW
and an extended throw code range will need concrete examples. My first
example is the SLURP-FILE example.

--
Krishna

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor