Re: Re(3): [colorforth] abort

[Jeff Penn <jeff+dated+1055971032.de5e09@xxxxxxxxxxxxxxxxxx>]

On Fri, Jun 13, 2003 at 09:29:57AM -0700, Samuel Falvo wrote:
> Despite a number of interesting responses, NOBODY thought about 
> returning a dummy image with human-readable text in it saying, "Bad 
> JPEG file" or some such in it.
>
> The advantage is clear: the human will readily see that there is a
> malformed JPEG file, and can take action appropriately, while the 
> software *ALWAYS* receives a valid bitmapped object, regardless of its
> input. 

Brilliant

> But when handling interactive or source-related manipulations, 'abort'> is a nice tool to drop back to the interpreter after displaying an 
> error message.  That is, after all, what it was originally put in 
> Forth for.  It was never really intended to become a general purpose 
> error display/handling routine.  It's too destructive for that: 
> besides dropping entirely out of the program and into the interpreter,
> it wipes both data and return stacks, and never bothers to close 
> files, free memory, etc.  It's a very rude word to execute, all in
> all.  People who use 'abort' for their general purpose error code 
> probably don't understand why it's there.  Consequently, in an attempt> to make it more "friendly" to the software's current environment, the 
> ANS standard redefined 'abort' to throw an exception which can be 
> caught.  It's a nice amenity, but shows evidence that they completely 
> miss the point.

My understanding is that Chuck intends that ColorForth should only 
really run on forth processors.  Abort on a forth processor with 
circular stacks is superfluous.

Jeff

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com