Just for the record, I'll repeat my standard disclaimer:
I'm a certified Python fan, Python handles most of these
problems as well or better than any other languages, especially
considering that it tries to stay within the bounds of what is
practical and implementable, and yes, I realize that some of the
problems with exceptions ARE problems "with exceptions", and
not specifically Python problems.
The same goes for the "pedantic type checking of arguments
in a dynamically typed OO language" problem. I posted a copy
of one of my messages from that thread to comp.lang.misc because
I thought it WAS a general problem for dynamic OO languages. I
got a reply that suggested that some OO languages ( Sather, for
example ) have separate inheritance for interface and implementation.
[ For example, a class can inherit the interface for "numeric-type"
or "sequence" , even if it doesn't inherit any methods from those
types. ] That sort of language capability HELP, but it doesn't
solve the problem without some well understood conventions outside
of the language. ( In fact, it has the same sort of semantic problems
as my proposed "is_numeric", etc., and it still leaves the possibility
of independently invention of similar abstract data types whose
functional identity is not detectable. )
> My first observation is that there are really *three* types of
> exceptions: bad arguments, programming errors, and "expected
> problems".
As an old friend of mine used to say: "There a two types of
people in the world: those who always go around saying 'there
are two types of people in the world...' and those who don't !"
Clearly Guido, you are NOT ONE OF *US* !
( Three? Geeze! ;-)
> The distinction between the first and the second isn't
> always clear, but in theory it is possible, and in practice often
> desirable, to protect your code against bad arguments. E.g. if an
> argument must be a non-empty list of strings, a few straightforward
> type checks can verify this.
But then we bump into the "pedantic typechecking" business again!
You guys just *recently* managed to convince me that I SHOULDN'T
explicitly check the type of args, because maybe a non-empty
sequence-LIKE object containing some string-LIKE objects would
do just as nicely if I didn't use type checking that was really
more restrictive than necessary. If any check is to be done,
then it should me a more general test that the object supports
the required operation - for example, NOT:
if type(arg) <> type( [] ): raise SomeException
arg.append( something )
BUT:
if not hasattr( arg, 'append' ): raise SomeException
arg.append( something )
OR JUST:
arg.append( something )
which will raise an exception if it doesn't have an 'append' method
ANYWAY, so the test is redundant. ( Unless we want to insist on the
EXPECTED error distinction. )
>
> Now the expected problems. Try statements are clumsy and have the
> disadvantages mentioned in earlier mails.
Exceptions have some problems, but Try...Except is easy to use.
And Python is intended to be easy to use and to try to do the
"right" thing by default, so I don't guess there is much purpose
in trying to argue that some of these "unexceptional" exceptions
shouldn't be using exceptions.
On Dec 16, 13:25, Bennett Todd wrote:
> Message-Id: <9312161825.AA18980@std.sbi.com>
>
> Anyway, back to your proposal, I am failing to see a useful definition of
> ``Expected error''. For things like end-of-file, the ``expected error''
> really just means you want out-of-band signaling --- which is in fact what
> you use for EOF. If something raises an exception, it should be (as I
> understand it) because things have gone wrong, and the best default behavior
> is to stop now, with a detailed explanation.
>
> -- End of excerpt from Bennett Todd <bet@std.sbi.com>
The method I think fit's best with an object oriented language is the
"return an error object" solution, where error-objects are
"contageous" : operations on error-objects usually yiend other
error-objects ( which may contain trace information for all of
the other previous errors. ) Explicit checks on whether an object
is an error-object replace try...except processing:
val = 1.0 / arg
if error( val ) && val.error == 'ZeroDivideError' :
val = something
return val
But then, this language would no longer be Python, it would be as
major a redesign as some of the effeciency redesign's in that other
thread.
On Dec 16, 16:33, Bennett Todd wrote:
> Message-Id: <9312162133.AA28060@std.sbi.com>
>
> But now I see the big defect in my idea; the current behavior is absolutely
> appropriate for ``can't happen'' problems, i.e. programmer errors. It's just
> wrong for user errors. How about if I revise my proposal.
>
> [ ... ]
>
> P.S. Are there any other exceptions I've missed, or are IOError and
> MemoryError the exhaustive list of exceptions raised due to environmental
> problems as reported by syscalls?
>
> -- End of excerpt from Bennett Todd <bet@std.sbi.com>
This, again, is one of the problems with exceptions: It's pretty darn
hard to tell if you've got all the bases covered. One has to either
rely on a lawyerly attention to the exact wording of the reference
manual, careful reading of the python source code, and/or experimental
coding: try to generate the kind of errors you expect and note down
what exceptions they generate.
BTW: I think I'm also missing something about the "letter bombs",
but I'll read this thread again. I see a different syntax but
I'm not sure I understand the different functionality.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics