My first Python program
python at mrabarnett.plus.com
Wed Oct 13 21:33:44 CEST 2010
On 13/10/2010 20:03, Seebs wrote:
> On 2010-10-13, Chris Rebert<clp2 at 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,
> 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
In practice I find that the Python way just works better.
More information about the Python-list