jaap> I tend to disagree. I think the end-user of an application will not
jaap> care about the internal structure of the application and/or the
jaap> techniques used to create it.
I agree with that sentence - but it's beside the point. The point I
was trying to make was:
I think the end-user of an CLASS will not care about the internal
structure of the CLASS and/or the techniques used to create it.
steve> "You are giving me garbage! - please read the instructions on
steve> how to use this class and/or method."
jaap> I can sympathize with the reasoning. I guess I would add rigid
jaap> checking as a debugging tool during development of an application.
Again - the distinction I was trying to make:
Type checking and some error checking that was put there to check
that the class actually works as it is supposed to, is a debugging
tool that can be removed when it has served it's purpose. Which is
to show that given the proper input, the class is consistent and
correct in it's behaviour.
Assuming for the moment that the class is bug free and consistent, it
should still give a reasonable error message when it is misused or
given the wrong input arguments.
To move the interface lines for a moment - what you are saying is
rather like:
"The program is bug free, so there is no need for error messages -
if the users give it the wrong input, it will crash and the OS
will tell them it crashed. They can then check their input files
and see what THEY did wrong. And even if there IS a bug, they
wouln't be interested in the details!"
No - the end user is not interested in the details of the program's
implementation. But they are interested in the distinction between:
'no such file', 'no privilege to read file', and 'input file incorrect
format'.
A related question is whether the default error messages are
sufficient. In many cases, the error message from 'deep in the
bowels' IS going to be the correct one. If it is a TypeError
when your try to actually USE the argument, then it was probably
going to be a TypeError raised if and when you checked it.
When I moved to unix from VMS, I had to adjust my programming
style somewhat. I had grown accustomed to the fact the VMS
default system error messages and behaviour were usually sufficient
that the program didn't need to do as much. The same programs
moved to unix gave incomprehensible messages ( or none at all )
And, in fact, the only problem with VMS messages was that they
often gave you all of the stack trace and other stuff not needed
by the end user. So the usual reason for adding explicit error
checking was to REMOVE information that was a distraction to the
end-user. 'No such filename' does NOT need a stack trace.
Specifically - python's default error behaviour is not bad -
the typical reason to change it is the same as in VMS - too
MUCH information.
In general, I'm saying that there is a distinction to be made
between implementor-oriented error messages ( This program/
procedure/class/shell-script/whatever has a BUG ) and end-user
oriented error messages ( You are feeding me the wrong imput. )
But in the case of reusable classes, another programmer
( or even the same programmer 6 months later ) is the "end-user"
of the class. The same inside/outside distinction is valid at
several levels of the hierarchy.
Rule: "You shouldn't have to open up a black box and take it
apart to find out you've been pushing the wrong buttons!"
Corollary: "Every black box should have at least TWO blinking
lights: "Paper Jam" and "Service Required" ( or equivalent )"
-Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
-Univ. of Virginia Department of Molecular Physiology and Biological Physics