those darn exceptions

[Chris Torek]

In article <96gb36Fc65U1 at mid.individual.net>,
Gregory Ewing  <greg.ewing at canterbury.ac.nz> wrote:
>Chris Torek wrote:
>
>> Oops!  It turns out that os.kill() can raise OverflowError (at
>> least in this version of Python, not sure what Python 3.x does).
>
>Seems to me that if this happens it indicates a bug in
>your code. It only makes sense to pass kill() something
>that you know to be the pid of an existing process,
>presumably one returned by some other system call.
>
>So if kill() raises OverflowError, you *don't* want
>to catch and ignore it. You want to find out about it,
>just as much as you want to find out about a TypeError,
>so you can track down the cause and fix it.

A bunch of you are missing the point here, perhaps because my
original example was "not the best", as it were.  (I wrote it
on the fly; the actual code was elsewhere at the time.)

I do, indeed, want to "find out about it".  But in this case
what I want to find out is "the number I thought was a pid,
was not a pid", and I want to find that out early and catch
the OverflowError() in the function in question.

(The two applications here are a daemon and a daemon-status-checking
program.  The daemon needs to see if another instance of itself is
already running [*].  The status-checking program needs to see if
the daemon is running [*].  Both open a pid file and read the contents.
The contents might be stale or trash.  I can check for trash because
int(some_string) raises ValueError.  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 *should*, for some value of "should" :-) , have turned up much
earlier, such as when running pylint.)

([*] The test does not have to be perfect, but it sure would be
nice if it did not result in a Python stack dump. :-) )
-- 
In-Real-Life: Chris Torek, Wind River Systems
Intel require I note that my opinions are not those of WRS or Intel
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html