In article <96gb36fc6...@mid.individual.net>, Gregory Ewing <greg.ew...@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
-- http://mail.python.org/mailman/listinfo/python-list