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, I
On Sun, Jun 26, 2011 at 12:28 AM, 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? The author of X, Y or Z? E
Chris Angelico wrote:
> On Sat, Jun 25, 2011 at 10:25 AM, Ben Finney
> 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
>>
On Sat, Jun 25, 2011 at 10:25 AM, Ben Finney 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 will be bound to when that
Chris Torek 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, any except
>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
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 o
In article <96gb36fc6...@mid.individual.net>,
Gregory Ewing 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 o
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. L
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 ex
>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 wrote:
>You can't. Even if you studied the source code, you coul
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 versi
In article
Chris Angelico 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
>d=1/(a+b-c) # This could throw ZeroDivisionError
>
>if a+b>c:
> d=
Chris Torek 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
> >>> os.k
On Tue, Jun 21, 2011 at 11:43 AM, Chris Torek 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.ki
15 matches
Mail list logo
