False positive --py3k exception-escape in generator expression

[jboning]

Steps to reproduce

1. Create file exception_escape_repro.py with contents:

def foo():
  try:
    return True
  except Exception as ex:
    all(bar for bar in ex.bars)

2. pylint --py3k exception_escape_repro.py

Current behavior

W:  5,23: Using an exception object that was bound by an except handler (exception-escape)

Expected behavior

No exception escape should be reported.

pylint --version output

$ pylint --version
No config file found, using default configuration
pylint 1.9.5, 
astroid 1.6.6
Python 2.7.16 (default, Jun 19 2019, 07:40:37) 
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)]

I verified that the issue also occurs with

pylint 2.4.0
astroid 2.3.0
Python 3.7.4 (default, Jul  9 2019, 18:13:23) 
[Clang 10.0.1 (clang-1001.0.46.4)]

---

I imagine this is due to the combination of function call and generator expression--the function call might store the generator for use later. It would be great if the analysis were clever enough to detect when that's not happening. I suppose this is asking for quite a lot though 🙂

[PCManticore]

Thanks for opening an issue. In this case we could exempt the usages of the exception inside its own except handler, so this is definitely a false positive.

[gabrieldrs]

Hello,

I took a look at this issue as I encountered it in a project I was working on.
The problem seems to be that, in order to know if the exception object is inside its exception handler, the rule is comparing the scope of the object (in the example ex) with the scope of the exception handler, and, in this case, the scope of ex is the generator. If we instead continued to go up in the parent chain, we would find the actual exception handler.

I imagine we could just check if the object ex is inside its exception handler by going up in the parent chain until we find its exception handler, or, if we end up in the root module, we would consider that it's being accessed outside its handler, do you think this approach would be correct?

I'm new to the project so I may be overlooking things a little, so, please, let me know. I could also put my "fix" idea together in a commit and share it with you.

[vphilippon]

Hello!

This fix landed on master, but after the 2.4 branch creation, so it didn't land in 2.4.4.
If possible (depending on 2.5.0 release timeline and/or if you have time for it), having a 2.4.5 with this fix would be super appreciated!

Thank you!