My first Python program

MRAB 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,
>> 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.



More information about the Python-list mailing list