On Fri, Feb 21, 2014 at 9:49 AM, Eli Bendersky <eliben@gmail.com> wrote:
On Fri, Feb 21, 2014 at 6:46 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 22 February 2014 00:37, Eli Bendersky <eliben@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.