forbidCheckedExceptionInYieldingMethod/forbidCheckedExceptionInCallable overlap for closures

[zacharylund]

With the addition of closures for forbidCheckedExceptionInYieldingMethod, there's now some overlap with forbidCheckedExceptionInCallable.

For example, Guzzle's Coroutine class accepts a generator and handles all exceptions. I've excluded it for forbidCheckedExceptionInCallable using allowedCheckedExceptionCallables:

forbidCheckedExceptionInCallable:
    allowedCheckedExceptionCallables:
        'GuzzleHttp\Promise\Coroutine::of': [0]

Now I need something similar for forbidCheckedExceptionInYieldingMethod. (Because of the nature of async/promises, it's not @param-immediately-invoked-callable.) I could see this reusing allowedCheckedExceptionCallables, but it might make more sense to duplicate that config:

forbidCheckedExceptionInYieldingMethod:
    allowedCheckedExceptionCallables:
        'GuzzleHttp\Promise\Coroutine::of': [0]

Hopefully that all makes sense. Thoughts?

[janedbal]

Hm, I knew about the overlap, but didnt realize this. Maybe forbidCheckedExceptionInYieldingMethod should only report closures that are @param-immediately-invoked-callable (which may get tricky)...