Re: Re(3): [colorforth] abort

[Samuel Falvo <falvosa@xxxxxxxxx>]

> I agree that they are different contexts, but I don't feel it has much to
> do with the distinction between open and closed systems. I think the user
> demographics targeted by iTV and colorForth/OKAD, respectively, play a
> considerably bigger role in defining the context of development.

The customers define the requirements for the applications, not the programming
environment.  This is a critical distinction, one which most language vendors
seem to forget.  One of the things that a customer will absolutely mandate is,
"The system must *never* crash."

As long as errors are handled as they are found, as locally as possible, there
can be *no* crashes.  Note that I consider the case of engineering the software
so that errors *cannot* happen to be a special case of handling the error.  It
just happens that it's done at design-time instead of run-time.

For example, while perusing the archives for this mailing list, Mark Slicker
wanted to know how to handle the case of a missing JPEG header for his JPEG
decoder software.  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.  E.g., as far as
the software is concerned, no error can ever occur.  Hence, there is no need to
expect one.

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.

--
Samuel A. Falvo II


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

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