Re: THROW codes and ambiguous conditions

On 31/05/2025 4:02 pm, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:
...

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.

 
It probably is not a problem, but your claim of a high cost seems
curious.  It seems to me that
 
open-file throw
 
is cheaper than
 
open-file abort" OPEN-FILE failed in INCLUDED"
 
and that reporting something like "Catch = -37" or somesuch is not
costly to implement at all.  And if you want more descriptive error
messages in a resource-constrained and otherwise traditional setting,
using the throw code to select a line from a sequence of blocks does
not seem to be particularly expensive, either.

It was simpler to let the app/library handle file errors which typically
include displaying the filename e.g.

\ DOS error handler
: ?DERR ( ior -- )
  ?dup if
    space  $FF and  cond
      2  of  ." file not found"  else
      3  of  ." path not found"  else
      4  of  ." too many open files"  else
      5  of  ." access denied"  else
      6  of  ." invalid handle"  else
      . ." DOS"
    cont  ."  error"  .abort
  then ;

\ If ior non-zero show handle filename and error
: ?FERR ( ior handle -- )
  over if  cr  .fname  ?derr  end  2drop ;

MS-DOS errors are mapped to 'ior' using $FExx (CHForth trick)

Other reasons for not going the ANS route was half the stack error msgs
and avoid managing a msg list (of which I'd need two as I use a split
dictionary).
 

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

 
It seems that if we have noticed it at all, many of us chose to ignore
it.

So it would appear - at least for file errors.  ISTR seeing Standard apps
trapping specific codes from the table but unsure now what they were.