Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news1.tnib.de!feed.news.tnib.de!news.tnib.de!news.belwue.de!rz.uni-karlsruhe.de!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail From: Bernd Paysan Newsgroups: comp.lang.forth Subject: Re: THROW and iors Date: Sat, 23 Jun 2012 23:17:19 +0200 Organization: 1&1 Internet AG Lines: 64 Message-ID: References: <4fe60471.71597048@192.168.0.50> NNTP-Posting-Host: p5dcd618a.dip0.t-ipconnect.de Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: online.de 1340486241 15111 93.205.97.138 (23 Jun 2012 21:17:21 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Sat, 23 Jun 2012 21:17:21 +0000 (UTC) User-Agent: KNode/4.8.4 Xref: csiph.com comp.lang.forth:13203 Stephen Pelc wrote: > I posted this around September 2006, but it was not the time. Now > some people seem to believe it is a good idea that ior return values > can be THROWn. Here it is again. No need for bringing this up again. As far as I can see from the current snapshot of Forth200x, this is already in, so you remembering that it wasn't a good time is probably wrong :-). Maybe you got too many flames. We accepted your proposal after some heavy discussions and minor modifications in 2007: http://www.forth200x.org/throw-iors.html However, I don't know who uses these additional error codes. We certainly use the biased OS error codes, which are also expicitely mentioned in Forth200x (and that was the minor modification which made me happy). In Gforth (similar in bigForth) we get s" /foo" r/w create-file throw :1: Permission denied s" /foo" r/w create-file >>>throw<<< or this s" /home/bernd" r/w create-file throw :2: Is a directory s" /home/bernd" r/w create-file >>>throw<<< And of course, "permission denied" or "is a directory" are outside the scope of a Forth standard, these are biased POSIX or Linux or even Windows error codes. And it is of course more useful than VFX Forth, where this throw currently still results in a silent abort. We use a special range of the throw-codes which are fed to strerror() (range (-2048,-512]) or strsignal() (range (-512;-256]). We map some error codes (especially from signals) to standard error codes, because that way they make more sense (especially a SIGSEGV can mean both an address violation as well as stack under/overflow). To go a bit further into discussion, there are some useful words in the error handling which have not yet found a way into the standard draft: We have .ERROR to display the error, and I think this is insufficiently factored, and there should be an ERROR$ (which I just have factored out) which converts the number to a meaningful string. Reference implementation might be something like : error$ ( n -- addr u ) \ human readable error string base @ >r decimal s>d tuck dabs <# #s rot sign s" error #" holds #> r> base ! ; Of course, while this is human readable, this still requires looking into the manual ;-). Furthermore, we have EXCEPTION ( addr u -- n ) which takes a string and returns an individual (consecutive) throw-code (in the system range (-4096,-2048]). When you pass that n to ERROR$, you get your string back. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/