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.
41 matches
Mail list logo
