Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: dxf <dxforth@gmail.com>
Newsgroups: comp.lang.forth
Subject: THROW codes and ambiguous conditions
Date: Sat, 31 May 2025 11:10:42 +1000
Organization: i2pn2 (i2pn.org)
Message-ID: <f827ba6fc80427f3ce0317835bd8ae47a4445e07@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 31 May 2025 01:10:44 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2625360"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="XPw7UV90Iy7EOhY4YuUXhpdoEf5Vz7K+BsxA/Cx8bVc";
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 1622
Lines: 16

AFAICS the statement in Section 9.3.5

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

effectively rules out the traditional use of ABORT" to convey the ambiguous
conditions listed in the table.  Is that how others read it?

Early on DX-Forth it became apparent that maintaining a list of error
messages accessible by means of a THROW code was going to be messy and
worse - costly.  I wanted CATCH THROW but could do without the vision
ANS appeared to have in mind for it.  The consequence of retaining
ABORT" for classic ambiguous conditions means I can't individually
identify them at CATCH but I've yet to find this a problem.

I'm curious whether others found ANS' requirement above 'a step too far'?