[Python-Dev] PEP 463: Exception-catching expressions

Brett Cannon brett at python.org
Fri Feb 21 16:19:25 CET 2014


On Fri, Feb 21, 2014 at 9:49 AM, Eli Bendersky <eliben at gmail.com> wrote:

> On Fri, Feb 21, 2014 at 6:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 22 February 2014 00:37, Eli Bendersky <eliben at gmail.com> wrote:
>> > This goes against anything I understand about how exceptions should and
>> > should not be used.
>>
>> I think you're thinking of a language that isn't Python - we use
>> exceptions for control flow all over the place (it's how hasattr() is
>> *defined*, for example).
>>
>
> No, it is Python I'm thinking about. As I mentioned in the reply to
> Brett's message, I see a difference between allowing exceptions on
> expression level and statement level. The latter is less likely to be
> abused. Once you add exceptions into expressions, all bets are off.
>
> For instance, it is sometime non-trivial to know which exceptions some
> function may throw. When you write a try...raise statement, you think hard
> about covering all the bases. In an expression you're unlikely to, which
> opens up a lot of possibilities for bugs. Again, please stop focusing just
> on the list[index] case -- the proposal adds a new significant feature to
> the language that can (and thus will) be used in a variety of scenarios.
>

I understand you are arguing that a try expression will lead to people just
doing `something() except Exception: None` or whatever and that people will
simply get lazy and not think about what they are doing with their
exceptions. Unfortunately they already are; that shipped sailed when we
didn't eliminate bare except clauses in Python 3 (hopefully we can change
that in Python 4).

I personally don't think that making people type out a try statement is
going to lead to that much thought compared to an expression. I'm willing
to bet most IDEs have a code snippet for creating a try statement so people
are already not using the extra typing of a full-blown statement with at
least two clauses as a way to stop and think about what they are doing.

I'm totally fine restricting this proposal to not having any concept of
exception catching or finally clause: it just replaces the simplest
try/except clause possible (while requiring an exception be specified).
That takes care of the common control flow use case of exceptions while
requiring more thought for more complex cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140221/67172654/attachment-0001.html>


More information about the Python-Dev mailing list