Prev: make a folder to .nsi file(which finally will convert to .exe) use python
Next: time between now and the next 2:30 am?
From: Nobody on 23 Jul 2010 17:46
On Fri, 23 Jul 2010 10:42:26 +0000, Steven D'Aprano wrote:

> Don't write bare excepts, always catch the error you want and nothing
> else.

That advice would make more sense if it was possible to know which
exceptions could be raised. In practice, that isn't possible, as the
documentation seldom provides this information. Even for the built-in
classes, the documentation is weak in this regard; for less important
modules and third-party libraries, it's entirely absent.

From: Benjamin Kaplan on 23 Jul 2010 18:04
On Fri, Jul 23, 2010 at 2:46 PM, Nobody <nobody(a)nowhere.com> wrote:
> On Fri, 23 Jul 2010 10:42:26 +0000, Steven D'Aprano wrote:
>
>> Don't write bare excepts, always catch the error you want and nothing
>> else.
>
> That advice would make more sense if it was possible to know which
> exceptions could be raised. In practice, that isn't possible, as the
> documentation seldom provides this information. Even for the built-in
> classes, the documentation is weak in this regard; for less important
> modules and third-party libraries, it's entirely absent.
>

You still don't want to use bare excepts.People tend to get rather
annoyed when you handle KeyboardInterrupts and SystemExits like you
would a UnicodeError. Use Exception if you don't know what exceptions
can be raised.
From: Thomas Jollans on 23 Jul 2010 18:04
On 07/23/2010 11:46 PM, Nobody wrote:
> On Fri, 23 Jul 2010 10:42:26 +0000, Steven D'Aprano wrote:
>
>> Don't write bare excepts, always catch the error you want and nothing
>> else.
>
> That advice would make more sense if it was possible to know which
> exceptions could be raised. In practice, that isn't possible, as the
> documentation seldom provides this information. Even for the built-in
> classes, the documentation is weak in this regard; for less important
> modules and third-party libraries, it's entirely absent.
>

In practice, at least in Python, it tends to be better to work the
"other way around": first, write code without exception handlers. Test.
If you get an exception, there are really two possible reactions:


1. "WHAT??"
=> This shouldn't be happening. Rather than catching everything,
fix your code, or think it through until you reach conclusion
#2 below.

2. "Ah, yes. Of course. I should check for that."
=> No problem! You're staring at a traceback right now, so you
know the exception raised.

If you know there should be an exception, but you don't know which one,
it should be trivial to create condition in which the exception arises,
should it not? Then, you can handle it properly, without resorting to
guesswork or over-generalisations.
From: Terry Reedy on 23 Jul 2010 18:27
On 7/23/2010 5:46 PM, Nobody wrote:
> On Fri, 23 Jul 2010 10:42:26 +0000, Steven D'Aprano wrote:
>
>> Don't write bare excepts, always catch the error you want and nothing
>> else.
>
> That advice would make more sense if it was possible to know which
> exceptions could be raised. In practice, that isn't possible, as the
> documentation seldom provides this information. Even for the built-in
> classes, the documentation is weak in this regard; for less important
> modules and third-party libraries, it's entirely absent.

I intend to bring that issue up on pydev list sometime. But in the
meanwhile, once you get an error, you know what it is. You can
intentionally feed code bad data and see what you get. And then maybe
add a test to make sure your code traps such errors.

--
Terry Jan Reedy

From: Steven D'Aprano on 23 Jul 2010 23:09
On Fri, 23 Jul 2010 22:46:46 +0100, Nobody wrote:

> On Fri, 23 Jul 2010 10:42:26 +0000, Steven D'Aprano wrote:
>
>> Don't write bare excepts, always catch the error you want and nothing
>> else.
>
> That advice would make more sense if it was possible to know which
> exceptions could be raised. In practice, that isn't possible, as the
> documentation seldom provides this information. Even for the built-in
> classes, the documentation is weak in this regard; for less important
> modules and third-party libraries, it's entirely absent.

Aside: that's an awfully sweeping generalisation for all third-party
libraries.

Yes, the documentation is sometimes weak, but that doesn't stop you from
being sensible. Catching any exception, no matter what, whether you've
heard of it or seen it before or not, is almost never a good idea. The
two problems with bare excepts are:

* They mask user generated keyboard interrupts, which is rude.

* They hide unexpected errors and disguise them as expected errors.

You want unexpected errors to raise an exception as early as possible,
because they probably indicate a bug in your code, and the earlier you
see the exception, the easier it is to debug.

And even if they don't indicate a bug in your code, but merely an under-
documented function, it's still better to find out what that is rather
than sweep it under the carpet. You will have learned something new ("oh,
the httplib functions can raise socket.error as well can they?") which
makes you a better programmer, you have the opportunity to improve the
documentation, you might want to handle it differently ("should I try
again, or just give up now, or reset the flubbler?").

If you decide to just mask the exception, rather than handle it in some
other way, it is easy enough to add an extra check to the except clause.



--
Steven
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: make a folder to .nsi file(which finally will convert to .exe) use python
Next: time between now and the next 2:30 am?