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


Groups > comp.lang.forth > #58004

Re: ABORT" alternatives

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: ABORT" alternatives
Date 2017-04-24 16:16 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2017Apr24.181642@mips.complang.tuwien.ac.at> (permalink)
References <dfb025c1-98d6-4de6-82f5-e0c3ca840b3a@googlegroups.com>

Show all headers | View raw


Julian Fondren <julian.fondren@gmail.com> writes:
>Or, you could use your Forth system's custom solution to this problem.
>
>gforth: provide a message, get a throw-code back.
>
>  s" a custom message" EXCEPTION constant my-exception
>
>  my-exception throw 
>  :3: a custom message
>  my-exception >>>throw<<<
>  Backtrace:
...
>SwiftForth: provide a message, get a throw-code back (while working a
>little bit more with the system)
>
>  THROW#
>    s" a custom message" >THROW enum my-exception
>  TO THROW#
>
>  my-exception throw a custom message
...
>VFX: provide a (parsed) message, get a throw-code constant:
>
>  ErrDef my-exception "a custom message"  ok
>  my-exception throw 
>  Err# 501 a custom message
>   -> my-exception throw
>                     ^

Hmm, it looks like there is a common need for defining new throw codes
(SwiftForth and VFX would never, ever add features speculatively), and
also common practice in doing it, only the syntax differs.  Time to
turn <http://www.forth200x.org/exception.html> into an RfD.

> oftentimes you
>want to say "I had a failure opening <this exact file>".

Or more likely: "<this exact file>: <OS error message>", e.g.,:

"/etc/shadow: permission denied"

The problem is that this does not fit the THROW model well.  However,
we already have a THROW-plus-string (ABORT"); we could extend the file
words such that, on error, they store the file name somewhere, and
when the ior is THROWn, the system's handler picks up the file name,
and finally prints the message.  That works with the current
interfaces, so there is no need to standardize it.  Systems could
already do this now, as part of their quality of implementation.

For what other cases do we need a composed string?  If we need one, we
can have a variant of EXCEPTION:

xt-exception ( xt -- n )
  where xt ( -- ) prints the error string

- 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 2016: http://www.euroforth.org/ef16/

Back to comp.lang.forth | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

ABORT" alternatives Julian Fondren <julian.fondren@gmail.com> - 2017-04-22 01:28 -0700
  Re: ABORT" alternatives Mark Wills <markwills1970@gmail.com> - 2017-04-22 01:59 -0700
    Re: ABORT" alternatives Julian Fondren <julian.fondren@gmail.com> - 2017-04-22 02:33 -0700
      Re: ABORT" alternatives "HAA" <someone@microsoft.com> - 2017-04-23 11:52 +1000
  Re: ABORT" alternatives anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-24 16:16 +0000

csiph-web