Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #84902
| 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) |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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