Re: [colorforth] abort

[Mark Slicker <maslicke@xxxxxxxxxxx>]

Interesting aproach. You are right, it is common today to see code which
is one part computational, one part diagnostic. I've never thought about
correcting errors in the input.

I suppose crashing is ok if you don't loose important information, and
boot times are minimal. However it is seen by many as an annoyance.

My particular need for abort comes in reexamining my jpeg decoder. It
seems convienent to abort if no image header is found. The image header
contains information such as width and height which alocates spaces for
the image from which a pointer is later returned. If no header is found
perhaps I could fake the decode an return a blank image.

Mark

On Mon, 2 Jun 2003, Chuck Moore wrote:

> Abort  generates indecision in my mind. I'm disturbed by all the words in
> ANSI Forth and have tried to minimize them.
>
> The concept of  catch  and  throw  are an example. They seem to emphasize
> the importance of errors. Much better to eliminate the possibility of error
> than to compensate for it. So I left out  abort.
>
> As a consequence, I sometimes have a crash that I could have avoided. On the
> other hand, if I can detect an error I can correct it. Or at least do
> something plausible rather than aborting.
>
> Perhaps it's time we made computers more intelligent.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
> Main web page - http://www.colorforth.com
>
>


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