On 6/21/2011 2:51 PM, Chris Torek wrote:
On Tue, 21 Jun 2011 01:43:39 +, Chris Torek wrote:
But how can I know a priori
that os.kill() could raise OverflowError in the first place?
If you passed an integer that was at some time a valid PID
to os.kill(), and OverflowError was raised,
Chris Angelico wrote:
On Sat, Jun 25, 2011 at 10:25 AM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
No. The answer is *still* “why, any exception at all”. The name
‘os.read’ could be re-bound at run-time to any object at all, so a code
checker that you “point at any given line of code”
On Sun, Jun 26, 2011 at 12:28 AM, steve+comp.lang.pyt...@pearwood.info wrote:
Chris Angelico wrote:
Sure it can. And KeyboardInterrupt could be raised at any time, too.
But this is a TOOL, not a deity. If Function X is known to call
Function Y and built-in method Z,
Known by whom? You? Me?
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
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
Chris Torek nos...@torek.net writes:
But again, this is why I would like to have the ability to use some
sort of automated tool, where one can point at any given line of
code and ask: what exceptions do you, my faithful tool, believe
can be raised as a consequence of this line of code?
“Why,
On Sat, Jun 25, 2011 at 10:25 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
No. The answer is *still* “why, any exception at all”. The name
‘os.read’ could be re-bound at run-time to any object at all, so a code
checker that you “point at any given line of code” can't know what the
name
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
On Thu, 23 Jun 2011 06:16 pm Gregory Ewing wrote:
Generally I think some people worry far too much about
anticipating and catching exceptions. Don't do that,
just let them happen. If you come across a specific
exception that it makes sense to catch, then catch
just that particular one. Let
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
On Tue, 21 Jun 2011 01:43:39 +, Chris Torek wrote:
Exceptions are great, but...
Sometimes when calling a function, you want to catch some or even all
the various exceptions it could raise. What exceptions *are* those?
[snip much, much interactive code]
TL;DR
*wink*
Shorter version:
On Tue, 21 Jun 2011 01:43:39 +, Chris Torek wrote:
But how can I know a priori
that os.kill() could raise OverflowError in the first place?
In article 4e006912$0$29982$c3e8da3$54964...@news.astraweb.com
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
You can't. Even if you
Exceptions are great, but...
Sometimes when calling a function, you want to catch some or
even all the various exceptions it could raise. What exceptions
*are* those?
It can be pretty obvious. For instance, the os.* modules raise
OSError on errors. The examples here are slightly silly until
I
On Tue, Jun 21, 2011 at 11:43 AM, Chris Torek nos...@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
Chris Torek nos...@torek.net writes:
It can be pretty obvious. For instance, the os.* modules raise OSError
on errors.
Not *only* OSError, of course.
The examples here are slightly silly until I reach the real code at
the bottom, but perhaps one will get the point:
import os
In article mailman.211.1308626356.1164.python-l...@python.org
Chris Angelico ros...@gmail.com wrote:
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
16 matches
Mail list logo
