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


Groups > comp.lang.python > #84871

Re: The Most Diabolical Python Antipattern

References <madpuv$he7$1@ger.gmane.org> <20150129113238.7eaa986d@bigbox.christie.dr> <mailman.18286.1422571931.18130.python-list@python.org> <87r3uchjyg.fsf@elektro.pacujo.net>
From Ian Kelly <ian.g.kelly@gmail.com>
Date 2015-01-30 02:11 -0700
Subject Re: The Most Diabolical Python Antipattern
Newsgroups comp.lang.python
Message-ID <mailman.18299.1422609145.18130.python-list@python.org> (permalink)

Show all headers | View raw


On Thu, Jan 29, 2015 at 11:16 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>> At least use "except Exception" instead of a bare except. Do you
>> really want things like SystemExit and KeyboardInterrupt to get turned
>> into 0?
>
> How about:
>
> ==============================
>     try:
>         do_interesting_stuff()
>     except ValueError:
>         try:
>             log_it()
>         except:
>             pass
>         raise
> ==============================

Are you asking if I think this is better? It still swallows arbitrary
exceptions. Why would you want to re-raise the anticipated (and
logged) ValueError instead of the exception that could potentially be
unexpected?

> Surprisingly this variant could raise an unexpected exception:
>
> ==============================
>     try:
>         do_interesting_stuff()
>     except ValueError:
>         try:
>             log_it()
>         finally:
>             raise
> ==============================
>
> A Python bug?

This does what it is supposed to. "If no expressions are present,
raise re-raises the last exception that was active in the current
scope." In this case, what that exception is depends on whether the
finally clause was entered as a result of an exception or fall-through
from the try clause. If you only want to re-raise the ValueError, then
use the first form above. If you only want to re-raise the other
exception, then do so from an except block (or don't catch it in the
first place).

Back to comp.lang.python | Previous | NextPrevious 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