[int] Check for ignored broad except

[sfayer]

This is another part of #8547. I've looked through all places where broad Exceptions are caught and then pass is used to ignore them. In most cases I've either made it more specific, added a log message or marked it as OK.

BEGINRELEASENOTES
*All
CHANGE: Check for ignored broad except
ENDRELEASENOTES

[sfayer]

It looks like my attempts to improve the Test_Profiler tests earlier today may need more work as that seems to have failed here again...

Regards,
Simon

[fstagni]

I can easily approve all these changes as they are improvements to what we have. Still:

• sometimes simply # nodes B110 is added, other times "proper" exception times are used. Why?
• sometimes pass is left after catching a broad Exception, others a message is printed out. I have the feeling the "correct" way, most of time would be to print a message.
• when we move from except Exception to, e.g., except (ValueError, TypeError, OSError), shouldn't we also add another broad except after? (I know, it's debatable)

[sfayer]

The general answer to all your questions is that I've been through each case by hand, looked at the context and tried to infer what the original author was intending to do. I've then tried to find any possible improvement on that.

* sometimes simply `# nodes B110` is added, other times "proper" exception times are used. Why?

The nosec comments were my last resort: These are the cases where I couldn't tighten up the exception types and the logger is unavailable or inappropriate. Or perhaps it's a try inside a branch that's already handling an error and we just want to do our best with the cleanup, but there is a good chance it'll fail (like sending a TLS shutdown while handling a socket error: that will likely fail but whatever happens we need to get to the socket.close()).

* sometimes `pass` is left after catching a broad `Exception`, others a message is printed out. I have the feeling the "correct" way, most of time would be to print a message.

Yes, I've tried to keep the ones where pass is left to a minimum. There a few different edge cases here, but it's generally things that are right down in service libraries which have no logger object available. In the other cases, it might be that the error handling is done outside of the except (i.e. it sets a variable to an object inside a try:, but can cope with it still being None later).

* when we move from `except Exception` to, e.g., `except (ValueError, TypeError, OSError)`, shouldn't we also add another broad except after? (I know, it's debatable)

In these instances I've been very careful to try to match up the exception list with what can be thrown inside the code block. The cases where other exceptions may be thrown here should be "impossible", yes it could happen if something really weird happens (MemoryError sorts of thing, or the code is changed later) but these should be really rare. I decided it would be better to let the exception propagate up in those extremely rare cases.

I believe I've successfully followed my "log wherever possible, unless it doesn't make sense" policy; I'm happy to discuss it further (especially if you have concerns about specific cases, where I can (hopefully!) explain my exact reasoning).

Regards,
Simon