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
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
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 mu
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
On Aug 21, 2:34 pm, Bruno Desthuilliers 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 os.acc
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),
Defens
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] wrot
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 prog
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
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 construc
> 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 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 a
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 j
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 p
eliben a écrit :
On Aug 21, 12:40 pm, Bruno Desthuilliers 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 with any gene
On Aug 21, 12:40 pm, Bruno Desthuilliers wrote:
> eliben a écrit :> On Aug 19, 7:19 pm, eliben <[EMAIL PROTECTED]> wrote:
> >> Python provides a quite good and feature-complete exception handling
> >
>
> > Thanks for the interesting discussion. Armed by the new information
> > and few online sour
> >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."
>
eliben a écrit :
On Aug 19, 7:19 pm, eliben <[EMAIL PROTECTED]> wrote:
Python provides a quite good and feature-complete exception handling
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 excepti
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
>
>
> Thanks for the interesting discussion. Armed by the new information and
> few online sources, I blogged a summar
[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, com
[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)
...
On Aug 19, 7:19 pm, eliben <[EMAIL PROTECTED]> wrote:
> Python provides a quite good and feature-complete exception handling
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 Pyth
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 co
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 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: pers
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 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 nothi
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):
>> >
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:
> > somethingB
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 le
[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 t
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
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 against keyboard>.
> """
I'm curious about the claim that open() will raise NameError in Python
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
""" 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 .
"""
This is *exactly* my concern with Python exceptions. You just never
know what can be thrown at you.
> You want to look up Easier to Ask Forgivness
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
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 Fo
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 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
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.
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 issues of exceptions are not specific to Python, but I
sometim
42 matches
Mail list logo
