Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #8323

Re: those darn exceptions

Show all headers | View raw

In article <96gb36Fc65U1@mid.individual.net>,
Gregory Ewing  <greg.ewing@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

those darn exceptions Chris Torek <nospam@torek.net> - 2011-06-21 01:43 +0000
  Re: those darn exceptions Chris Angelico <rosuav@gmail.com> - 2011-06-21 13:19 +1000
    Re: those darn exceptions Chris Torek <nospam@torek.net> - 2011-06-21 04:40 +0000
  Re: those darn exceptions Ben Finney <ben+python@benfinney.id.au> - 2011-06-21 14:04 +1000
  Re: those darn exceptions Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-21 09:49 +0000
    Re: those darn exceptions Chris Torek <nospam@torek.net> - 2011-06-21 21:51 +0000
      Re: those darn exceptions John Nagle <nagle@animats.com> - 2011-06-27 11:52 -0700
  Re: those darn exceptions Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-06-23 20:16 +1200
    Re: those darn exceptions Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-23 18:40 +1000
    Re: those darn exceptions Chris Torek <nospam@torek.net> - 2011-06-23 18:33 +0000
      Re: those darn exceptions Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-06-24 19:50 +1200
        Re: those darn exceptions Chris Torek <nospam@torek.net> - 2011-06-24 18:21 +0000
          Re: those darn exceptions Ben Finney <ben+python@benfinney.id.au> - 2011-06-25 10:25 +1000
            Re: those darn exceptions Chris Angelico <rosuav@gmail.com> - 2011-06-25 13:55 +1000
              Re: those darn exceptions steve+comp.lang.python@pearwood.info - 2011-06-26 00:28 +1000
                Re: those darn exceptions Chris Angelico <rosuav@gmail.com> - 2011-06-26 01:52 +1000

csiph-web