Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Awsome Python - chained exceptions

Reply
Thread Tools

Awsome Python - chained exceptions

 
 
Steven D'Aprano
Guest
Posts: n/a
 
      02-12-2013
As an antidote to the ill-informed negativity of Ranting Rick's
illusionary "PyWarts", I thought I'd present a few of Python's more
awesome features, starting with exception contexts.

If you've ever written an exception handler, you've probably written a
*buggy* exception handler:


def getitem(items, index):
# One-based indexing.
try:
return items[index-1]
except IndexError:
print ("Item at index %d is missing" % index - 1) # Oops!


Unfortunately, when an exception occurs inside an except or finally
block, the second exception masks the first, and the reason for the
original exception is lost:

py> getitem(['one', 'two', 'three'], 5) # Python 2.6
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 6, in getitem
TypeError: unsupported operand type(s) for -: 'str' and 'int'


But never fear! In Python 3.1 and better, Python now shows you the full
chain of multiple exceptions, and exceptions grow two new special
attributes: __cause__ and __context__.

If an exception occurs while handling another exception, Python sets the
exception's __context__ and displays an extended error message:


py> getitem(['one', 'two', 'three'], 5) # Python 3.1
Traceback (most recent call last):
File "<stdin>", line 4, in getitem
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 6, in getitem
TypeError: unsupported operand type(s) for -: 'str' and 'int'



Python 3 also allows you to explicitly set the exception's __cause__
using "raise...from" syntax:

py> try:
.... len(None)
.... except TypeError as e:
.... raise ValueError('bad value') from e
....
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
TypeError: object of type 'NoneType' has no len()

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "<stdin>", line 4, in <module>
ValueError: bad value



Note the slight difference in error message. If both __cause__ and
__context__ are set, the __cause__ takes priority.


Sometimes you actually want to deliberately catch one exception and raise
another, without showing the first exception. A very common idiom in
Python 2:


try:
do_work()
except SomeInternalError:
raise PublicError(error_message)


Starting with Python 3.3, there is now support from intentionally
suppressing the __context__:


py> try:
.... len(None)
.... except TypeError:
.... raise ValueError('bad value') from None # Python 3.3
....
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
ValueError: bad value



You can read more about exception chaining here:

http://www.python.org/dev/peps/pep-3134/
http://www.python.org/dev/peps/pep-0409/



--
Steven
 
Reply With Quote
 
 
 
 
Terry Reedy
Guest
Posts: n/a
 
      02-12-2013
On 2/12/2013 1:15 AM, Steven D'Aprano wrote:
> As an antidote to the ill-informed negativity of Ranting Rick's
> illusionary "PyWarts", I thought I'd present a few of Python's more
> awesome features, starting with exception contexts.


You do not need Rick to justify such an informative post.

> If you've ever written an exception handler, you've probably written a
> *buggy* exception handler:
>
>
> def getitem(items, index):
> # One-based indexing.
> try:
> return items[index-1]
> except IndexError:
> print ("Item at index %d is missing" % index - 1) # Oops!
>
>
> Unfortunately, when an exception occurs inside an except or finally
> block, the second exception masks the first, and the reason for the
> original exception is lost:
>
> py> getitem(['one', 'two', 'three'], 5) # Python 2.6
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<stdin>", line 6, in getitem
> TypeError: unsupported operand type(s) for -: 'str' and 'int'
>
>
> But never fear! In Python 3.1 and better, Python now shows you the full
> chain of multiple exceptions, and exceptions grow two new special
> attributes: __cause__ and __context__.


Some thought was given to having only one special attribute, but in the
end it was decided to have __context__ be the actual context and
__cause__ be the programmer set and displayed 'context'.

> If an exception occurs while handling another exception, Python sets the
> exception's __context__ and displays an extended error message:
>
> py> getitem(['one', 'two', 'three'], 5) # Python 3.1
> Traceback (most recent call last):
> File "<stdin>", line 4, in getitem
> IndexError: list index out of range
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<stdin>", line 6, in getitem
> TypeError: unsupported operand type(s) for -: 'str' and 'int'
>
> Python 3 also allows you to explicitly set the exception's __cause__
> using "raise...from" syntax:
>
> py> try:
> ... len(None)
> ... except TypeError as e:
> ... raise ValueError('bad value') from e
> ...
> Traceback (most recent call last):
> File "<stdin>", line 2, in <module>
> TypeError: object of type 'NoneType' has no len()
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
> File "<stdin>", line 4, in <module>
> ValueError: bad value
>
> Note the slight difference in error message. If both __cause__ and
> __context__ are set, the __cause__ takes priority.
>
> Sometimes you actually want to deliberately catch one exception and raise
> another, without showing the first exception. A very common idiom in
> Python 2:
>
> try:
> do_work()
> except SomeInternalError:
> raise PublicError(error_message)
>
> Starting with Python 3.3, there is now support from intentionally
> suppressing the __context__:
>
> py> try:
> ... len(None)
> ... except TypeError:
> ... raise ValueError('bad value') from None # Python 3.3
> ...
> Traceback (most recent call last):
> File "<stdin>", line 4, in <module>
> ValueError: bad value
>

The new features are explained in the Library manual, Ch. 5, Exceptions,
but without so many clear examples. The 'from None' option has not yet
been added to the Language reference section on raise statements (an
issue on the tracker), so it is easy to miss if one does not also read
the Library chapter.
>
> You can read more about exception chaining here:
>
> http://www.python.org/dev/peps/pep-3134/
> http://www.python.org/dev/peps/pep-0409/


--
Terry Jan Reedy

 
Reply With Quote
 
 
 
 
Zero Piraeus
Guest
Posts: n/a
 
      02-12-2013
:

On 12 February 2013 02:15, Steven D'Aprano
<(E-Mail Removed)> wrote:
> As an antidote to the ill-informed negativity of Ranting Rick's
> illusionary "PyWarts", I thought I'd present a few of Python's more
> awesome features [...]


You could call them PyW00ts.

-[]z.
 
Reply With Quote
 
Ethan Furman
Guest
Posts: n/a
 
      02-12-2013
On 02/12/2013 10:01 AM, Zero Piraeus wrote:
> On 12 February 2013 02:15, Steven D'Aprano wrote:
>> As an antidote to the ill-informed negativity of Ranting Rick's
>> illusionary "PyWarts", I thought I'd present a few of Python's more
>> awesome features [...]

>
> You could call them PyW00ts.


+1 QOTW

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-13-2013
On Tuesday, February 12, 2013 12:15:29 AM UTC-6, Steven D'Aprano wrote:
> [snip inflammatory remarks]
> I thought I'd present a few of Python's more
> awesome features, starting with exception contexts.


Well that's great idea, however, in order to find this very "valuable" information the searcher must not only remember an unintuitive search tag, he must also remember /exactly/ how you misspelled the unintuitive search tag! I sure hope you have more of these "Awsome Python"'s to share because i fear this one will surely be forgotten in 2 days.

> If you've ever written an exception handler, you've probably written a
> *buggy* exception handler:
>
> def getitem(items, index):
> # One-based indexing.
> try:
> return items[index-1]
> except IndexError:
> print ("Item at index %d is missing" % index - 1) # Oops!
>
>
> Unfortunately, when an exception occurs inside an except or finally
> block, the second exception masks the first, and the reason for the
> original exception is lost:
>
> py> getitem(['one', 'two', 'three'], 5) # Python 2.6
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<stdin>", line 6, in getitem
> TypeError: unsupported operand type(s) for -: 'str' and 'int'


But that's exactly what any sane person wants to happen. And i don't know why your error messages are so vague because i got this message (using IDLE):

py> getitem([1,2,3], 5)
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
getitem([1,2,3], 5)
File "<pyshell#1>", line 5, in getitem
print ("Item at index %d is missing" % index - 1) # Oops!
TypeError: unsupported operand type(s) for -: 'str' and 'int'

Which (by showing the offensive line) is quite clear to me. I even tried a simplified version on the command line (to make sure IDLE was not injectinganything) and got a better exception message, but sadly without the offending line:

py> try:
.... l[10]
.... except IndexError:
.... "{0}".format(blah)
....
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
NameError: name 'blah' is not defined

But in either case, both forms of the message i got are far more helpful than the exception you posted. Did you trim the exception in an attempt to sensationalize the problem?

But who cares about the exception message python returned when there are /so/ many abominations in this code sample. I mean, i know this is an example, but it should not be an example of "how not to code"+"ANYTHING"+"!"*10

Some of the problems include:

1. You are using the print function (so we can assume you are using Python 3.x) but then you go and use that old ugly "%" string interpolation syntax crap! when you should have used the format method of strings.

print("Item at index {0} is missing".format(index-1)) # Oops!

....Oh Steven, if you only knew how we interpreted the "Oops!", more like "Doh!".

2. Your stdout message is not only confusing, it's a freaking lie!

"Item at index %d is missing".

....Steven, i can assure you that if "list[index]" raises an IndexError, theitem is NOT /missing/. Neither the item OR the index even /exist/ as far as the sequence is concerned. Contrary to your naive beliefs, Python sequences are not initialized with every possible integer index (that the current machine can represent) just sitting around twiddling their thumbs complaining of boredom whilst waiting for a value to come along they can point to; can you imagine the memory usage of such a design (flaw)?

3. Your claim that the broken code in the "exception block" masks the exception that would have been raised by the code in the "try block" is false, because if it's true, then you'd better find the fool who told Python to mask the try block in the first place!

Got any more bright ideas DeAprano? (Oh gawd that felt good!)
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-13-2013
On Tuesday, February 12, 2013 12:01:45 PM UTC-6, Zero Piraeus wrote:

> You could call them PyW00ts.


+1 on the name
-INFINITY on the execution

Actually i am happy that DeAprano used the unintuitive tag now. Bad enough to use an unintuitive tag. Worse to misspell it. But it would been a crime to tarnish such an intuitive tag as "PyW00ts" with the clumsy teachings provided.
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-13-2013
On Tuesday, February 12, 2013 12:01:45 PM UTC-6, Zero Piraeus wrote:

> You could call them PyW00ts.


+1 on the name
-INFINITY on the execution

Actually i am happy that DeAprano used the unintuitive tag now. Bad enough to use an unintuitive tag. Worse to misspell it. But it would been a crime to tarnish such an intuitive tag as "PyW00ts" with the clumsy teachings provided.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      02-13-2013
On Wed, Feb 13, 2013 at 1:47 PM, Rick Johnson
<(E-Mail Removed)> wrote:
>On Tuesday, February 12, 2013 12:15:29 AM UTC-6, Steven D'Aprano wrote:
>> If you've ever written an exception handler, you've probably written a
>> *buggy* exception handler:
>>
>> def getitem(items, index):
>> # One-based indexing.
>> try:
>> return items[index-1]
>> except IndexError:
>> print ("Item at index %d is missing" % index - 1) # Oops!
>>
>>
>> Unfortunately, when an exception occurs inside an except or finally
>> block, the second exception masks the first, and the reason for the
>> original exception is lost:
>>
>> py> getitem(['one', 'two', 'three'], 5) # Python 2.6
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File "<stdin>", line 6, in getitem
>> TypeError: unsupported operand type(s) for -: 'str' and 'int'

>
> Which (by showing the offensive line) is quite clear to me.


No, the offending (not offensive) line is "return items[index-1]",
which doesn't feature in your traceback at all. It DOES, however,
feature in the Py3.1 double traceback (it's listed as line 4)..

> 1. You are using the print function (so we can assume you are using Python 3.x)


He is? Could just as easily be the print statement with a single
argument, with unnecessary parentheses around that argument. Which, if
I recall correctly, is one of the recommended approaches for making
2/3 bi-compatible code.

> but then you go and use that old ugly "%" string interpolation syntax crap! when you should have used the format method of strings.
>
> print("Item at index {0} is missing".format(index-1)) # Oops!
>
> ...Oh Steven, if you only knew how we interpreted the "Oops!", more like "Doh!".


No. Definitely not. Percent interpolation isn't going anywhere - core
devs have said so - and there are many occasions when it is at least
as well suited to the task as .format() is. Also, it's a notation
that's well understood *across languages* and in a variety of message
interpolation systems. Anyone who's worked with *any* of them will
understand that %s inserts a string, %d a number (in decimal), etc,
etc. Granted, the exact details after that may change (eg Python has
%r to emit the representation, while Pike uses %O for "any object",
with similar notation), but the format specifiers and modifiers that
came from C are fairly stable, readable, and compact.

In what way is a trivial example like this improved by the use of
format()? The ONLY thing I can think of is that, by forcing you to put
parentheses around the argument, it avoids the issue from the original
post, which is one of operator precedence - but that's something
that's fairly easy to spot when you know what you're looking for, and
is definitely not specific to string formatting.

ChrisA
 
Reply With Quote
 
Michael Torrie
Guest
Posts: n/a
 
      02-13-2013
On Feb 13, 2013 12:00 AM, "Chris Angelico" <(E-Mail Removed)> wrote:

> Which word? "we"? I'm not entirely sure, given that non-monospaced
> fonts get in the way. Normally people would put exactly as many >

carets/tildes as there are letters in the word, but aligning the text
> in a mono font puts the carets under "we", so that clue isn't there.


Sorry I assumed that on a technical list like this one folks would be
viewing emails as the internet gods intended, in a nice monospace font.

I don't see how leading carets would help in a proportional font; it just
doesn't work well for quoting emails I think. Maybe that's why email from
html clients seem to do a lot of top posting and ditch quoting (and I fear
reading) emails all together.

Apologies if the quoted stuff is messed up in this email. Darn phones are
not good at doing proper emailing.

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-13-2013
On Wednesday, February 13, 2013 12:58:46 AM UTC-6, Chris Angelico wrote:
> On Wed, Feb 13, 2013 at 1:47 PM, Rick Johnson wrote:
> >On Tuesday, February 12, 2013 12:15:29 AM UTC-6, Steven D'Aprano wrote:
> >> If you've ever written an exception handler, you've probably written a
> >> *buggy* exception handler:
> >>
> >> def getitem(items, index):
> >> # One-based indexing.
> >> try:
> >> return items[index-1]
> >> except IndexError:
> >> print ("Item at index %d is missing" % index - 1) # Oops!
> >>
> >>
> >> Unfortunately, when an exception occurs inside an except or finally
> >> block, the second exception masks the first, and the reason for the
> >> original exception is lost:
> >>
> >> py> getitem(['one', 'two', 'three'], 5) # Python 2.6
> >> Traceback (most recent call last):
> >> File "<stdin>", line 1, in <module>
> >> File "<stdin>", line 6, in getitem
> >> TypeError: unsupported operand type(s) for -: 'str' and 'int'

> >
> > Which (by showing the offensive line) is quite clear to me.

>
> No, the offending (not offensive) line is "return items[index-1]",
> which doesn't feature in your traceback at all.


Do you realize that you are quoting DeAprano and not me? Whether you realize this fact or not, consider the next two questions.

Q1: How could a line in the "try" block ever be considered
offensive? Because it throws an error? Are you serious?

Q2: Why would the line in the try block be shown as
a "feature" of the traceback when the whole intent of
exception handling is to hide the error in the try
block! If you want to raise the exception in the try block
then you place a naked raise statement in the exception
block, BUT THEN, why even wrap the code in a try/except
in the first damn place!?

Man, you and DeAprano must be cut from the same block; or more correctly, carved by the same shaky hand of a creator suffering the late-stage effects of Alzheimers disease.

> It DOES, however,
> feature in the Py3.1 double traceback (it's listed as line 4)..
>
> > 1. You are using the print function (so we can assume you are using Python 3.x)

>
> He is? Could just as easily be the print statement with a single
> argument, with unnecessary parentheses around that argument. Which, if
> I recall correctly, is one of the recommended approaches for making
> 2/3 bi-compatible code.


Really?

Because if he did in-fact write the print statement using parenthesis (in some foolish attempt to make his code forward-compatible) that would mean i should add /another/ coding abomination to my earlier list of abominations.The proper method of using a forward compatible print function is by /importing/ the feature.

from future import print_function

> No. Definitely not. Percent interpolation isn't going anywhere - core
> devs have said so - and there are many occasions when it is at least
> as well suited to the task as .format() is.


In other words: Screw consistency and to hell with the zen?

> Also, it's a notation
> that's well understood *across languages* and in a variety of message
> interpolation systems. Anyone who's worked with *any* of them will
> understand that %s inserts a string, %d a number (in decimal), etc,


Oh yes, because indexing the list of arguments in the format method is SO much more overhead! Heck, Python>=2.7 (read the docs for exact release number) will allow you to implicitly pass the index:

print "{} is one more than {}".format("five", "four") # 3.something

....is equivalent to:

print "{0} is one more than {1}".format("five", "four")

....but what about when you need to substitute the /same/ substring in more than one location? Using the old nasty interpolation you are foced to writethis:

print "Chris is a %s who is very %s-ish"%('troll', 'troll')

....ewwww yuck! String.format() to the rescue!

print "Chris is a {0} who is very {0}-ish".format('troll')

In fact all of these posted examples work in Python>=2.7.

So the moral is: You can pass no indexes and the format method will intuit the indexes from their linear position in the string, or you can pass indexes and be explicit (plus you can reference a value more than once!), or youcan choose one of the many other great options available of the format method.

http://docs.python.org/2/library/str...-string-syntax

> etc. Granted, the exact details after that may change (eg Python has
> %r to emit the representation, while Pike uses %O for "any object",
> with similar notation), but the format specifiers and modifiers that
> came from C are fairly stable, readable, and compact.


The fact is that "str.format(args)" beats the pants off string interpolation any day and anybody arguing for keeping string interpolation is not thinking clearly (especially when they first claim consistency between languagesand them expose that claim as a lie) and is also anti-pythonic! To continue to propagate foolish language designs simply because other people have been brainwashed by them is, well, foolish. Would you propagate propaganda using the same excuse?

> In what way is a trivial example like this improved by the use of
> format()? The ONLY thing I can think of is that, by forcing you to put
> parentheses around the argument,


You think the only difference between string.format() and string interpolation is parenthesis? Chris, just because you don't understand how to use str..format() (or interpolation!) correctly does not mean other python programmers are unable too.

> it avoids the issue from the original
> post, which is one of operator precedence - but that's something
> that's fairly easy to spot when you know what you're looking for, and
> is definitely not specific to string formatting.


So as you say: str.format() solves a bug in the code, but that is not enough excuse to stop using the old cryptic and bug inducing interpolation syntax. I see[1].

[1] Read as: "I see that you are a lost cause". Hopefully you will grow a brain and read the format docs, and then try to apply it in your code, then MAYBE you will understand why i support str.format as the only method to format a string.

PS: Why do keep posting email addresses on the list? Does your client not trim, or at least warn, about these?
 
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
Chained RDP over chained VPN Frank Winkler Cisco 2 06-20-2008 08:02 AM
chained exceptions Rowland Smith Python 0 06-10-2008 04:18 PM
Chained exceptions in Perl Ivan Fomichev Perl Misc 0 05-04-2007 08:44 AM
Looking for an awsome 3d multi monitor screensaver, Jeremy NZ Computing 7 03-11-2006 07:00 AM
Can abbreviated printStackTrace() output be easily prevented for chained exceptions? Mike H Java 1 02-27-2004 04:09 PM



Advertisments