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


Groups > comp.lang.python > #84902

Re: The Most Diabolical Python Antipattern

References (6 earlier) <87fvaslh9h.fsf@elektro.pacujo.net> <mailman.18306.1422631319.18130.python-list@python.org> <87zj90jngf.fsf@elektro.pacujo.net> <mailman.18307.1422632572.18130.python-list@python.org> <87vbjojm86.fsf@elektro.pacujo.net>
From Ian Kelly <ian.g.kelly@gmail.com>
Date 2015-01-30 09:38 -0700
Subject Re: The Most Diabolical Python Antipattern
Newsgroups comp.lang.python
Message-ID <mailman.18312.1422635977.18130.python-list@python.org> (permalink)

Show all headers | View raw


On Fri, Jan 30, 2015 at 8:56 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>> Like I suggested earlier, just don't catch the inner exception at all.
>> The result will be both exceptions propagated, chained in the proper
>> order.
>
> Depends on the situation.

Like what? If you want to specifically propagate the original
exception in order to be caught again elsewhere, then I think there's
a code smell to that. If this inner exception handler doesn't
specifically know how to handle a ValueError, then why should some
outer exception handler be able to handle an exception that could have
come from virtually anywhere?

A better approach to that would be to create a specific exception
class that narrowly identifies what went wrong, and raise *that* with
the other exceptions chained to it. E.g.:

  try:
      do_interesting_stuff()
  except ValueError as e:
      try:
          log_it()
      except Exception:
          # Chain both exceptions as __context__
          raise SpecificException
      else:
          # Chain the original exception as __cause__
          raise SpecificException from e

Or if you don't care about distinguishing __cause__ from __context__:

  try:
      do_interesting_stuff()
  except ValueError:
      try:
          log_it()
      finally:
          raise SpecificException

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