Lie a écrit :
On Aug 21, 12:59 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Wed, 20 Aug 2008 09:23:22 -0700, [EMAIL PROTECTED] wrote:
On Aug 19, 4:12 pm, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED]
Lie wrote:
Ah... now I understand what the Zen is talking about when it said:
Now is better then never, although never is often better than *right*
now. If you don't have all the necessary resources to fix an
exception right now, don't try to fix it, instead let it propagate,
and allow it to
Bruno Desthuilliers @ Thursday 21 August 2008 22:54:
magloca a écrit :
Bruno Desthuilliers @ Thursday 21 August 2008 17:31:
If you mean the exceptions *explicitely raised* by your code,
then I agree. But with any generic enough code, documenting any
possible exception that could be raised
Le Thursday 21 August 2008 09:34:47 Bruno Desthuilliers, vous avez écrit :
The point
is that EAFP conflicts with the interest of reporting errors as soon
as possible (on which much has been written see, for instance Ch. 8 -
Defensive Programming in Code Complete),
Defensive programming
On Aug 21, 12:59 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Wed, 20 Aug 2008 09:23:22 -0700, [EMAIL PROTECTED] wrote:
On Aug 19, 4:12 pm, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED] wrote:
def
Maric Michaud a écrit :
Le Thursday 21 August 2008 09:34:47 Bruno Desthuilliers, vous avez écrit :
The point
is that EAFP conflicts with the interest of reporting errors as soon
as possible (on which much has been written see, for instance Ch. 8 -
Defensive Programming in Code Complete),
On Aug 21, 2:34 pm, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] a écrit :
On Aug 19, 4:12 pm, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED] wrote:
def do_something(filename):
if not
On Fri, 22 Aug 2008 06:43:58 -0700 (PDT), Lie wrote:
I think we should change except: into expect:, it would confuse less,
would it? It signifies that the program expects so and so kinds of
exceptional situations. The try: should also be changed to... perhaps
in:, block:, onthiscode:, etc
Le Friday 22 August 2008 15:03:21 Bruno Desthuilliers, vous avez écrit :
Maric Michaud a écrit :
Le Thursday 21 August 2008 09:34:47 Bruno Desthuilliers, vous avez écrit :
The point
is that EAFP conflicts with the interest of reporting errors as soon
as possible (on which much has been
En Thu, 21 Aug 2008 14:48:45 -0300, magloca [EMAIL PROTECTED]
escribió:
Bruno Desthuilliers @ Thursday 21 August 2008 17:31:
Java's checked exception system has proven to be a total disaster.
Could you elaborate on that? I'm not disagreeing with you (or agreeing,
for that matter); I'd
One common-place thing I've noticed in a lot of python code is that
every package or module has a main Error class, and all sub-types
inherit from that class. So you just catch mylib.Error, and you're
going to catch all the exceptions that package generates directly.
There seems to be a lot of
On Aug 19, 7:19 pm, eliben [EMAIL PROTECTED] wrote:
Python provides a quite good and feature-complete exception handling
snip
Thanks for the interesting discussion. Armed by the new information
and few online sources, I blogged a summary for myself on the topic of
robust exception handling in
[EMAIL PROTECTED] a écrit :
On Aug 19, 4:12 pm, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED] wrote:
def do_something(filename):
if not os.access(filename,os.R_OK):
return err(...)
f = open(filename)
...
[EMAIL PROTECTED] a écrit :
(snip)
Here is an example: a simple query tool for a tiny mock SQL
relational database. With a method (called select_all) you can
perform the equivalent of a select query on the database. The contents
of the query are specified with triples of the form
[field,
On Thu, 21 Aug 2008 00:34:21 -0700, eliben wrote:
On Aug 19, 7:19 pm, eliben [EMAIL PROTECTED] wrote:
Python provides a quite good and feature-complete exception handling
snip
Thanks for the interesting discussion. Armed by the new information and
few online sources, I blogged a summary
eliben a écrit :
On Aug 19, 7:19 pm, eliben [EMAIL PROTECTED] wrote:
Python provides a quite good and feature-complete exception handling
snip
Thanks for the interesting discussion. Armed by the new information
and few online sources, I blogged a summary for myself on the topic of
robust
http://eli.thegreenplace.net/2008/08/21/robust-exception-handling/
Just a few random points. You say:
Exceptions are better than returning error status codes. Some languages
(like Python) leave you with no choice as the whole language core and
standard libraries throw exceptions.
Of
On Aug 21, 12:40 pm, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
eliben a écrit : On Aug 19, 7:19 pm, eliben [EMAIL PROTECTED] wrote:
Python provides a quite good and feature-complete exception handling
snip
Thanks for the interesting discussion. Armed by the new information
and
eliben a écrit :
On Aug 21, 12:40 pm, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
eliben a écrit : On Aug 19, 7:19 pm, eliben [EMAIL PROTECTED] wrote:
(snip)
Document the exceptions thrown by your code
If you mean the exceptions *explicitely raised* by your code, then I
agree. But
Bruno Desthuilliers @ Thursday 21 August 2008 17:31:
If you mean the exceptions *explicitely raised* by your code, then
I agree. But with any generic enough code, documenting any possible
exception that could be raised by lower layers, objects passed in as
arguments etc is just plain
magloca a écrit :
Bruno Desthuilliers @ Thursday 21 August 2008 17:31:
If you mean the exceptions *explicitely raised* by your code, then
I agree. But with any generic enough code, documenting any possible
exception that could be raised by lower layers, objects passed in as
arguments etc is
On Aug 20, 10:13 pm, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
It might not be enjoyable to have a sarcastic remark directed your way,
but it isn't a personal attack. Just because a comment is about something
you do doesn't make it a personal attack. Personal attacks are about
Here is an example from a Django web app: when there is a bug, a
generic Exception is thrown and Django catches it and reports a
beautifully formatted stack trace. When something must be reported to
the user, a MyAppException is thrown (not the real name). The HTTP
request handler for the
On Aug 19, 7:34 pm, Chris Mellon [EMAIL PROTECTED] wrote:
On Tue, Aug 19, 2008 at 12:19 PM, eliben [EMAIL PROTECTED] wrote:
Python provides a quite good and feature-complete exception handling
mechanism for its programmers. This is good. But exceptions, like any
complex construct, are
On Tue, 19 Aug 2008 22:24:45 -0700, eliben wrote:
You want to look up Easier to Ask Forgivness than Permission (EAFP)
which is touted as the canonical error-handling paradigm for Python.
Any (semi)complete guides on this canonical paradigm online ? I've only
found some references in
On Tue, 19 Aug 2008 22:24:45 -0700, eliben wrote:
between file()
and open() in Python 2 and 3, a NameError is thrown with open() in
Python 3 and an IOError is thrown in the other three cases bashes head
against keyboard.
I'm curious about the claim that open() will raise NameError in
On Aug 19, 4:12 pm, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED] wrote:
def do_something(filename):
if not os.access(filename,os.R_OK):
return err(...)
f = open(filename)
...
You're running on a
[EMAIL PROTECTED] a écrit :
On Aug 19, 10:19 am, eliben [EMAIL PROTECTED] wrote:
P.S. There's a common case where a method is passed a filename, to do
something with a file (say, read data). Should the method catch the
errors possibly thrown by open(), or leave it to the caller ?
You want to
eliben a écrit :
This is *exactly* my concern with Python exceptions. You just never
know what can be thrown at you.
This rarely happen to be a problem in real life. At least not in mine.
Exception that can be expected (ie : IOError when dealing with files)
are usually obvious and more or
On Aug 20, 12:47 am, Fredrik Lundh [EMAIL PROTECTED] wrote:
Rafe wrote:
Again, this is probably too simple to help, but the only way to ignore
certain types of exceptions, as far as I know, is to catch them and
pass.
e.g. this ignores type errors...
try:
somethingBad()
except
On Wed, 20 Aug 2008 09:23:22 -0700, [EMAIL PROTECTED] wrote:
On Aug 19, 4:12 pm, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED] wrote:
def do_something(filename):
if not os.access(filename,os.R_OK):
return
On Wed, 20 Aug 2008 18:37:02 +0200, Bruno Desthuilliers wrote:
I personally think this is sloppy because you have to couple the
exception type with the function --- between file() and open() in
Python 2 and 3, a NameError is thrown with open() in Python 3
??? I suspect this has nothing to
On Aug 20, 10:59 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
Oh goodie. Another programmer who goes out of his way to make it hard for
other programmers, by destroying duck-typing.
Remember kids: personal attacks are cruise control for cool.
So this was a simplification -
On Wed, 20 Aug 2008 17:49:14 -0700, [EMAIL PROTECTED] wrote:
On Aug 20, 10:59 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
Oh goodie. Another programmer who goes out of his way to make it hard
for other programmers, by destroying duck-typing.
Remember kids: personal
En Wed, 20 Aug 2008 21:49:14 -0300, [EMAIL PROTECTED] [EMAIL PROTECTED]
escribió:
On Aug 20, 10:59 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
Oh goodie. Another programmer who goes out of his way to make it hard for
other programmers, by destroying duck-typing.
On Tue, Aug 19, 2008 at 12:19 PM, eliben [EMAIL PROTECTED] wrote:
Python provides a quite good and feature-complete exception handling
mechanism for its programmers. This is good. But exceptions, like any
complex construct, are difficult to use correctly, especially as
programs get large.
On Aug 20, 12:19 am, eliben [EMAIL PROTECTED] wrote:
Python provides a quite good and feature-complete exception handling
mechanism for its programmers. This is good. But exceptions, like any
complex construct, are difficult to use correctly, especially as
programs get large.
Most of the
Rafe wrote:
Again, this is probably too simple to help, but the only way to ignore
certain types of exceptions, as far as I know, is to catch them and
pass.
e.g. this ignores type errors...
try:
somethingBad()
except TypeError, err:
pass
except Exception, err:
raise TypeError(err)
On Aug 19, 10:19 am, eliben [EMAIL PROTECTED] wrote:
P.S. There's a common case where a method is passed a filename, to do
something with a file (say, read data). Should the method catch the
errors possibly thrown by open(), or leave it to the caller ?
You want to look up Easier to Ask
On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED] wrote:
def do_something(filename):
if not os.access(filename,os.R_OK):
return err(...)
f = open(filename)
...
You're running on a multitasking modern machine, right? What happens when
some other process deletes
between file()
and open() in Python 2 and 3, a NameError is thrown with open() in
Python 3 and an IOError is thrown in the other three cases bashes
head against keyboard.
This is *exactly* my concern with Python exceptions. You just never
know what can be thrown at you.
You want to look up
41 matches
Mail list logo
