On 13/10/2010 20:03, Seebs wrote:
On 2010-10-13, Chris Rebert<c...@rebertia.com> wrote:
For future reference, the significant majority of things in Python
raise exceptions upon encountering errors rather than returning error
values of some sort.
Yes. I'm getting used to that -- it's a bit of a shift, because I'm
used to exceptions being *exceptional* -- as in, not a failure mode
you would expect to see happening. So for instance, I wouldn't expect
to get an exception for EOF, because that's not exceptional, that's
virtually guaranteed to happen whenever you interact with files. I am
gonna have to retrain a bit.
Aside from APIs which explicitly provide a parameter to be returned as
a default value in case of error (e.g. getattr(obj, name, default)),
the only common exception* I can come up with off the top of my head
is str.find()**, and even that has an exception-throwing cousin,
str.index().
Interesting! That may take me some getting used to.
Basically, Python tries to avoid returning 'magic' values which you
need to check, but could equally just ignore.
If it can't open a file, it doesn't return None, it complains.
If it can't parse an int from a string, it doesn't return 0 (which it
could return if it's successful) or None or whatever, it complains.
There are times when, say, C# complains but Python doesn't, like trying
to get a substring starting at a position which is off the end of the
source string.
In practice I find that the Python way just works better.
--
http://mail.python.org/mailman/listinfo/python-list
