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

Groups > comp.lang.python > #8061

Re: those darn exceptions

Show all headers | View raw

On Tue, Jun 21, 2011 at 11:43 AM, Chris Torek <nospam@torek.net> wrote:
> It can be pretty obvious.  For instance, the os.* modules raise
> OSError on errors.  The examples here are slightly silly until
> I reach the "real" code at the bottom, but perhaps one will get
> the point:
>
>    >>> import os
>    >>> os.kill(getpid(), 0) # am I alive?
>    >>> # yep, I am alive.
>    ...
>
> [I'm not sure why the interpreter wants more after my comment here.]
>

It's not wanting more. It responded to your statement "yep, I am
alive" by boggling at you. It said, and I quote, "...". What next?
Reading the obituaries column in search of your own PID?

Yep, slightly silly. And very amusing. But back to the serious:

os.kill(pid,0) doesn't work on Windows, but that just means this whole
function can't be used on Windows. (Actually, the kill call DOES work.
It just doesn't do what you want here... it kills the process.)

os.kill("asdf",0) --> TypeError: an integer is required
os.kill(-1,0) --> no error raised - not sure if you want to propagate
os.kill()'s behaviour on negative PIDs or not - see for instance
http://linux.die.net/man/2/kill

I'm not sure if it's possible to put Python into "secure computing"
mode (with prctl(PR_SET_SECCOMP) on Linux), but if you did, then
there'd be an additional possible result from this: No return at all,
because your process has just been killed for trying to kill someone
else. (Secure Computing: The death penalty for attempted murder.)

Interesting concept of pulling out all possible exceptions. Would be
theoretically possible to build a table that keeps track of them, but
automated tools may have problems:

a=5; b=7; c=12
d=1/(a+b-c) # This could throw ZeroDivisionError

if a+b>c:
  d=1/(a+b-c) # This can't, because it's guarded.
else:
  d=2

And don't tell me to rewrite that with try/except, because it's not the same :)

I'd be inclined to have comments about the exceptions that this can
itself produce, but if there's exceptions that come from illogical
arguments (like the TypeError above), then just ignore them and let
them propagate. If is_process("asdf") throws TypeError rather than
returning False, I would call that acceptable behaviour.

Chris Angelico

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