Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Gregory Ewing <greg.ewing@canterbury.ac.nz>
Newsgroups: comp.lang.python
Subject: Re: those darn exceptions
Date: Fri, 24 Jun 2011 19:50:34 +1200
Lines: 31
Message-ID: <96itucFadiU1@mid.individual.net>
References: <itot0b022i@news4.newsguy.com> <96gb36Fc65U1@mid.individual.net> <iu00uh2dhg@news3.newsguy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net OVpbDcNXkBIGIOdIF0omSgCtsKXpLF1xQrrnZxSkHU9K/7fo9g
Cancel-Lock: sha1:sggEuqaEyo1nsjS+KB3dsIFM8z8=
User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711)
X-Accept-Language: en-us, en
In-Reply-To: <iu00uh2dhg@news3.newsguy.com>
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:8359

Chris Torek wrote:
> I can then check the now-valid
> pid via os.kill().  However, it turns out that one form of "trash"
> is a pid that does not fit within sys.maxint.  This was a surprise
> that turned up only in testing, and even then, only because I
> happened to try a ridiculously large value as one of my test cases.

It appears that this situation is not unique to os.kill(),
for example,

 >>> import os
 >>> os.read(999999999999999999999999, 42)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

In fact I'd expect it to happen any time you pass a
very large int to something that's wrapping a C function.

You can't really blame the wrappers for this -- it's not
reasonable to expect all of them to catch out-of-range ints
and do whatever the underlying function would have done if
it were given an invalid argument.

I think the lesson to take from this is that you should
probably add OverflowError to the list of things to catch
whenever you're calling a function with input that's not
fully validated.

-- 
Greg