Re: LOGO-L> QUESTION ON CONDITIONAL OUTPUTS

[George Mills <mills@softronix.com>]

In real world applications it is not unusual to have
10 times the code for error checking compared to functional
code. It does not matter if it makes your code less pretty
or less readable or less fun. It's something that just plain
has to be done.

This is one of the primary reason Programmers Underestimate
their schedules. They think about the problem and estimate
I can write that in a week. Three months later they are still
adding error checking. You always hear things like "Well
I never thought the user was stupid enough to do that" Or
"Oooh, I never thought of that".

Adding error checking is much like stating your assumptions
in a proof.

A young programmer should understand the value of
good error checking.

>         ADDLISTS doesn't like [3 4 A 6] as input

Again these arguments seem trivial either way with the
ADDLISTS example. But when programs get large and complex
with one thing built on top of another good skills in
making the code readable and error checking
begin to pay back.

This could just as easily say:

ADDLISTS doesn't like the non numeric element 3 in the input [3 4 A 6]

You can can go overboard and have error checking cause
errors, bugs or even perfoemance problems. That's why I
consider programming more of an engineering practice than a
science. Just as a Mechanical Engineer needs to deterimine
the right size beam when building a bridge, a programming
engineer needs to decide the right amount of comments,
error Checking, Diagnostics, Testing etc.

jstclair@omsd.cerf.fred.org wrote:
> 
> Please reply to bh@anarres.CS.Berkeley.EDU (Brian Harvey)  or
> logo-l@gsn.org  NOT   logo-list@gsn.org  or  me.
> 
>                         -John-
> --Message below re-posted by <jstclair@omsd.cerf.fred.org>
> Date - 23 Apr 1998 01:13:10 GMT
> >From - bh@anarres.CS.Berkeley.EDU (Brian Harvey)
> To - jcstclair@omsd
> Subject - Re: LOGO-L> QUESTION ON CONDITIONAL OUTPUTS
> Usenet: comp.lang.logo
> ------------------
> Post Usenet mail to comp-lang-logo@ucbvax.berkeley.edu
> ------------------
> 
> George Mills <mills@softronix.com> writes:
> >Error checking is also something that I think I see
> >way to little of.
> >For example in the ADDLISTS example.
> >A VERY obvious error check would be both lists
> >contain the same amount of elements.
> >Also check that each element contains something
> >that can be "added".
> 
> This is one of the standard pieces of programming-class advice
> that I'm not sure I believe.  Especially the second part.  It
> seems to me that the basic difference is whether you see
>         ADDLISTS doesn't like [3 4 A 6] as input
> or
>         + doesn't like A as input
> in the error message that you're going to get whether or not
> addlists checks explicitly.  I'm not sure that the first message
> (the one you'll get if addlists checks for the error) is really
> better than the second (which you'll get if addlists doesn't check).
> 
> The important difference is the second line, the one that tells you
> where the error happened; if addlists is a library procedure (and
> therefore supposedly bug-free :-) you'd like to see where your own
> procedure called addlists, rather than where addlists called +.
> But that's what my proposed pretend-this-is-a-primitive feature
> would accomplish, without a lot of error-checking code in addlists.
> 
> In a compiler or something (e.g., in the Logo interpreter itself),
> it's worth putting a lot of effort into error detection because
> there are so many complicated ways to go wrong and you want to give
> the user as much help as you can.  But in addlists, six instructions
> long, adding another six instructions for error checking just makes
> the code hard to read and understand.
> 
> It's different if the error check is going to do something other than
> just print a message.  In the classic case, if the error check is
> going to turn off an x-ray machine that's otherwise going to burn
> a patient to death, then by all means the check should be made!
> But if the whole point of the check is to print a slightly different
> error message, I don't see it.
> 
> I can also see a case for checking, in addlists, whether the second
> list is longer than the first.  Logo will catch the other way around,
> but in this case it'll just return an answer as if the second list
> were truncated at the right place.  Maybe this will lead to the
> program giving erroneous but seemingly-okay results, when an error
> message would be better.
> 
> On the other hand, Lisp code historically takes advantage of this
> lack-of-error-check!  Let's say you have the addlists procedure
> and you want to add 3 to every element of an arbitrary-length
> list of numbers.  You can say
>         ? make "threes (list 3)
>         ? .setbf :threes :threes
>         ? show addlists [1 4 100] :threes
>         [4 7 103]
> The second instruction effectively turned :threes into a list
> of infinitely many threes!  If you try to print it, Logo will
> go into a loop saying [3 3 3 3 3 3 ... (except if you have
> printwidthlimit set, it'll stop eventually).  But you can
> use it as the second input to addlists and it'll work no matter
> how long the first input is.

-- 
===============================================================
George Mills
email: mills@softronix.com
http://www.softronix.com
The www page contains some very powerful educational software.
Our single most important investment is our kids.
-- 
===============================================================
George Mills
email: mills@softronix.com
http://www.softronix.com
The www page contains some very powerful educational software.
Our single most important investment is our kids.
---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org.  Mail
questions about the list administration to logofdn@gsn.org.  To
unsubscribe send    unsubscribe logo-l    to majordomo@gsn.org.