Removing broad-exception-raised lint rule and updates

[joesho112358]

Summary

#9614 removing broad-exception-raised

Details and comments

Updates for removing the broad-exception-raised rule

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @enavarro51
• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 9032720722

Details

• 1 of 6 (16.67%) changed or added relevant lines in 4 files are covered.
• 13 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.007%) to 89.638%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/synthesis/clifford/clifford_decompose_bm.py	0	1	0.0%
qiskit/visualization/bloch.py	0	2	0.0%
qiskit/visualization/transition_visualization.py	0	2	0.0%

Files with Coverage Reduction	New Missed Lines	%
qiskit/transpiler/passes/synthesis/unitary_synthesis.py	2	88.2%
crates/qasm2/src/lex.rs	5	92.11%
crates/qasm2/src/parse.rs	6	97.61%

Totals
Change from base Build 9032084393:	0.007%
Covered Lines:	62208
Relevant Lines:	69399

---

💛 - Coveralls

[jakelishman]

Thanks for looking at this - this is definitely a good lint to get enabled. I left a couple of comments about avoiding RuntimeError - we usually try and avoid that one as much as possible because there's generally some tighter bound to apply. It's all a little bit subjective of course, but we (at least I!) generally try to keep RuntimeError for exceptions in defensive programming bits amongst ourselves, like if an internal private invariant has somehow become violated.

(Fwiw, it matters rather less what we use in tests, since if we're ever raising an Exception in tests, it's usually just to indicate a test failure or something.)

[joesho112358]

Thanks for looking at this - this is definitely a good lint to get enabled. I left a couple of comments about avoiding RuntimeError - we usually try and avoid that one as much as possible because there's generally some tighter bound to apply. It's all a little bit subjective of course, but we (at least I!) generally try to keep RuntimeError for exceptions in defensive programming bits amongst ourselves, like if an internal private invariant has somehow become violated.

(Fwiw, it matters rather less what we use in tests, since if we're ever raising an Exception in tests, it's usually just to indicate a test failure or something.)

seems fair to me! updates are in for another look

[jakelishman]

Thanks for the changes! One comment about a pre-existing test that ought to be written in a different way, otherwise this is good to merge.

[jakelishman]

This is pre-existing, stemming from the previous implementation of these magic methods being incorrect, but in general we don't want to call __mul__ directly - NotImplemented is just a sentinel value that's properly interpreted by Python. The normal forms of these tests would be

with self.assertRaises(TypeError):
    _ = self.quat_unnormalized * other_array

and similar for the other one.

This actually means that Python will also try the __rmul__ methods on other_array and other_scalar as well before raising the TypeError, in case either of those classes is something that can explicitly handle multiplication by Quaternion, though in this case, both will fail. The Numpy array test will actually start to succeed (Numpy will attempt to broadcast the multiplication), but then it'll fail the internal scalar multiplication.

[joesho112358]

i see. yeah, i was thinking this was more of a unit test vs integration test. updates on the way!

[jakelishman]

Ace, thanks for the changes!