Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Suggesting the use of StandardError as base of error Exceptions.

Reply
Thread Tools

Suggesting the use of StandardError as base of error Exceptions.

 
 
Antoon Pardon
Guest
Posts: n/a
 
      03-06-2006
In a number of cases I have a program that looks like the following.

for case in all_cases:
try:
treat(case)
except Exception, ErrInfo:
generate_traceback()

The idea is to get as much information as possible when something
goes wrong but at the same time treat as many cases as possible.

Then one day things broke. The reason was that in some circumstances
treat would decide that things were beyond control and called sys.exit
However sys.exit doesn't return to the O.S. immediately but raises
SystemExit, which was caugth by the code and the loop continued.

I then took a look at http://docs.python.org/lib/module-exceptions.html
which describes the exception heirarchy as follows:

Exception
+-- SystemExit
+-- StopIteration
+-- StandardError
| +
| + All kind of error exceptions
| +
+---Warning
+
+ All kind of warnings
+

and came to the conclusion, that it would be better to write my code
as follows:

for case in all_cases:
try:
treat(case)
except StandardError, ErrInfo:
generate_traceback()

Unfortunatly this doesn't work either because a lot of the error
exceptions in the stdlib (if not all) inherit directly from
Exception instead of from StandardError. The documentation also
seems to suggest this use for users exception.

Now I was wondering if it wouldn't be better that for exception
that indicate some error condition that these would inherit
from StandardError and that this would be indicated in the
documentation and reflected in the stdlib?

Would it break much code to make this change? My first impression
would be no, but I could be missing something.

--
Antoon Pardon
 
Reply With Quote
 
 
 
 
Diez B. Roggisch
Guest
Posts: n/a
 
      03-06-2006
Antoon Pardon schrieb:
> In a number of cases I have a program that looks like the following.
>
> for case in all_cases:
> try:
> treat(case)
> except Exception, ErrInfo:
> generate_traceback()
>
> The idea is to get as much information as possible when something
> goes wrong but at the same time treat as many cases as possible.
>
> Then one day things broke. The reason was that in some circumstances
> treat would decide that things were beyond control and called sys.exit
> However sys.exit doesn't return to the O.S. immediately but raises
> SystemExit, which was caugth by the code and the loop continued.
>
> I then took a look at http://docs.python.org/lib/module-exceptions.html
> which describes the exception heirarchy as follows:
>
> Exception
> +-- SystemExit
> +-- StopIteration
> +-- StandardError
> | +
> | + All kind of error exceptions
> | +
> +---Warning
> +
> + All kind of warnings
> +
>
> and came to the conclusion, that it would be better to write my code
> as follows:
>
> for case in all_cases:
> try:
> treat(case)
> except StandardError, ErrInfo:
> generate_traceback()
>
> Unfortunatly this doesn't work either because a lot of the error
> exceptions in the stdlib (if not all) inherit directly from
> Exception instead of from StandardError. The documentation also
> seems to suggest this use for users exception.
>
> Now I was wondering if it wouldn't be better that for exception
> that indicate some error condition that these would inherit
> from StandardError and that this would be indicated in the
> documentation and reflected in the stdlib?
>
> Would it break much code to make this change? My first impression
> would be no, but I could be missing something.


There has been a discussion on this just a few days ago, have you read that? There is even a PEP mentioned.

http://groups.google.com/group/comp....403ae0c6267ca1


Diez

 
Reply With Quote
 
 
 
 
Kent Johnson
Guest
Posts: n/a
 
      03-06-2006
Diez B. Roggisch wrote:
> Antoon Pardon schrieb:
>> Now I was wondering if it wouldn't be better that for exception
>> that indicate some error condition that these would inherit
>> from StandardError and that this would be indicated in the
>> documentation and reflected in the stdlib?
>>
>> Would it break much code to make this change? My first impression
>> would be no, but I could be missing something.

>
>
> There has been a discussion on this just a few days ago, have you read
> that? There is even a PEP mentioned.


It's PEP 352, it's already done. This will be in Python 2.5. It's good
to see that the time machine is stil working
http://www.python.org/peps/pep-0352.html

Kent
 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      03-06-2006
Antoon Pardon wrote:
> I then took a look at http://docs.python.org/lib/module-exceptions.html
> which describes the exception heirarchy as follows:
>
> Exception
> +-- SystemExit
> +-- StopIteration
> +-- StandardError
> | +
> | + All kind of error exceptions
> | +
> +---Warning
> +
> + All kind of warnings
> +
>
> and came to the conclusion, that it would be better to write my code
> as follows:
>
> for case in all_cases:
> try:
> treat(case)
> except StandardError, ErrInfo:
> generate_traceback()


You've already been pointed to `PEP 352`_, but just to highlight the
salient point, I believe what you want to write is::

try:
...
except (KeyboardInterrupt, SystemExit):
raise
except:
...

... _PEP 352: http://www.python.org/peps/pep-0352.html

STeVe
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
StandardError in Python 2 -> 3 Steven D'Aprano Python 1 11-17-2012 01:51 AM
Suggesting methods with similar names bearophileHUGS@lycos.com Python 11 04-02-2005 07:40 PM
Suggesting a new feature - "Inverse Generators" Jordan Rastrick Python 22 03-27-2005 06:58 AM
Help suggesting new URL richard Computer Support 0 09-29-2003 10:51 AM
Suggesting for overloading the assign operator Rim Python 20 07-08-2003 06:50 PM



Advertisments