Re(2): [colorforth] abort

["Arthur W. Green" <goshawk@xxxxxxxxx>]

Sorry I didn't respond to this earlier.

>However, for an application that uses 'foreign' generated data, especially
>high level abstractions, 'Abort', 'catch' and 'throw', 'divide by zero'
checks
>and whatever else you can think of are all required. Case in point would be a
>simple HTML processor with graphic image displayer. There is definitely
a need
>to detect bad as well as missing syntax in order to recover to a known state
>and continue with the overall operation.
>
Words like 'abort', 'catch' and 'throw', and others feel a little non
sequitur to me, at least for most (if not all) applications. These error-
handling constructs seem too "system level" to be belonging in most
"application level" code.

I think the only reason you need to "fall back" to a known state is that
either 1) you don't know how to proceed after running into an error or 2)
you don't know what the current state is at that point in the code. I
think the former shouldn't have to happen in most application level code.
I think the latter is unacceptable in most cases.


I'm thinking of especially an HTML processor. Consider that the vast
majority of HTML code out on the web is laden with errors (which is
true), then I would think errors are the *rule* for an HTML processor not
the *exception*. If you design with that consideration in mind, you can
make your code much more tolerant to hitches in "foreign" data without
compromising stability or simplicity by taking the route of system level
error handling everytime something relatively benign goes wrong.

For example, can't find an end tag when there should be one there? Or run
across a bad attribute? Decide on a default behaviour of some kind, such
as artificially closing the tag for the purposes of the viewer, or
inserting a default attribute (or making an educated guess) and move on.
I don't think consider these system level errors, and I don't think it
should even be remotely treated as such.


I also think most users rely too much on words like 'catch'/'throw'
because they have historically relied completely on the OS to do the job
of error-handling. Something goes "wrong", and the application code
basically looks to the OS and says "Do something!". To me, this is a
throwback from a bygone era of mainframe administration, when users were
placed in tiny boxes imposed by the machine so that they would "play
nice" with other users who were sharing the machine. Maybe I don't know
what I am talking about, but for the most part, I don't how see how this
is needed in stand-alone Forths.

-- Art



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