Re(2): [colorforth] abort

["t" <loveall@xxxxxxxxx>]

Arthur,

Sorry, I wasn't clear. It doesn't matter what names or what logic structures
one uses to handle error laden data. The point is that there are two entirely
different development contexts:

1) Closed, data controlled environments such as industrial process control,
standalone development systems or anywhere that the computer generates all
data such as in colorForth.

2) Open, external communication based systems like DOS, linux, Windows and the
ill-fated iTV project.

Read Jeff Fox's comments on the application development for iTV and then read
Chuck's comments about develpping colorForth and OKAD. Radically different
contexts.

I have been lusting after developing a communication based 'closed box' system
for some time now. The perfect example of what I am talking about can be found
at:
http://dunkels.com/adam/contiki/
Contiki is a multi-tasking, graphical OS with TCP/IP stack, web browser/server
and telnet client all in 42k. It is written in C.

Unfortunately, I haven't had the time to pursue this, but I do contemplate it.

Trying to figure out whether colorForth with its non-standard character
encoding would be a good fit, or to use the ASCII'd colorForth or my own
flat-real mode 4word. 

The differences are worth soaking up a few beers over, discussing the merits
of the various implementations, but are actually moot until such time as
someone in the community produces a TCP/IP stack.

Regards,
Terry Loveall

On Fri, 13 Jun 2003 00:38:01 -0400
"Arthur W. Green" <goshawk@xxxxxxxxx> wrote:

> 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