Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #84891

Re: The Most Diabolical Python Antipattern

Show all headers | View raw

On Fri, Jan 30, 2015 at 3:00 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Marko Rauhamaa <marko@pacujo.net>:
>
>>>> Surprisingly this variant could raise an unexpected exception:
>>>>
>>>> ==============================
>>>>      try:
>>>>          do_interesting_stuff()
>>>>      except ValueError:
>>>>          try:
>>>>              log_it()
>>>>          finally:
>>>>              raise
>>>> ==============================
>>>>
>>>> A Python bug?
>> [...]
>> My Python did do exception chaining, but the problem is the surface
>> exception changes, which could throw off the whole error recovery.
>
> BTW, the code above can be fixed:
>
> ==============================
>   try:
>       do_interesting_stuff()
>   except ValueError as e:
>       try:
>           log_it()
>       finally:
>           raise e
> ==============================
>
> Now the surface exception is kept and the subsidiary exception is
> chained to it.
>
> I'm a bit baffled why the two pieces of code are not equivalent.

The bare raise re-raises the most recent exception that is being
handled. The "raise e" raises that exception specifically, which is
not the most recent in the case of a secondary exception.

Note that the exceptions are actually chained *in reverse*; the
message falsely indicates that the secondary exception was raised
first, and the primary exception was raised while handling it, e.g.:

Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
TypeError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 7, in <module>
  File "<stdin>", line 2, in <module>
ValueError

That's because "raise e" causes the exception e to be freshly raised,
whereas the bare "raise" merely makes the existing exception context
active again.

It's interesting to note here that although the exception retains its
original traceback information (note the two separate lines in the
traceback), it is not chained again from the TypeError. One might
expect to actually see the ValueError, followed by the TypeError,
followed by the ValueError in the chain. That doesn't happen because
the two ValueErrors raised are actually the same object, and Python is
apparently wise enough to break the chain to avoid an infinite cycle.

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: The Most Diabolical Python Antipattern Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-29 15:51 -0700
  Re: The Most Diabolical Python Antipattern Marko Rauhamaa <marko@pacujo.net> - 2015-01-30 08:16 +0200
    Re: The Most Diabolical Python Antipattern Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-30 08:10 +0000
      Re: The Most Diabolical Python Antipattern Marko Rauhamaa <marko@pacujo.net> - 2015-01-30 11:02 +0200
        Re: The Most Diabolical Python Antipattern Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-30 02:17 -0700
        Re: The Most Diabolical Python Antipattern Marko Rauhamaa <marko@pacujo.net> - 2015-01-30 12:00 +0200
          Re: The Most Diabolical Python Antipattern Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-30 08:21 -0700
            Re: The Most Diabolical Python Antipattern Marko Rauhamaa <marko@pacujo.net> - 2015-01-30 17:30 +0200
              Re: The Most Diabolical Python Antipattern Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-30 08:42 -0700
                Re: The Most Diabolical Python Antipattern Marko Rauhamaa <marko@pacujo.net> - 2015-01-30 17:56 +0200
                Re: The Most Diabolical Python Antipattern Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-30 09:38 -0700
              Re: The Most Diabolical Python Antipattern Chris Angelico <rosuav@gmail.com> - 2015-01-31 02:55 +1100
    Re: The Most Diabolical Python Antipattern Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-30 02:11 -0700
    Re: The Most Diabolical Python Antipattern Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-31 01:28 +0000

csiph-web