Qiskit / coheriq / 41546885011

93%

push

github

Report the right type, and stay in the CoheriqError hierarchy (#52)

Two pre-existing problems in how `acceleration_candidate` and `override`
resolve a lookup name.

A non-string `name` reported the type of the decorated function rather
than of `name` itself, so `name=123` complained `got function instead`.
The branch is only reachable when `name` is given, since a name derived
from `__name__` is always a string, so `type(f)` was never the right
thing to report there.

Reading `f.__name__` unguarded raised a bare `AttributeError` naming a
dunder.  That escaped the CoheriqError hierarchy, so a caller wrapping
setup in `except CoheriqError` did not catch it.  It affected two
different situations: a caller error such as passing an int, and
legitimate callables that carry no `__name__`, which includes
`functools.partial` objects and instances of classes defining
`__call__`.  Both now raise CoheriqDomainError or CoheriqEngineError and
point at the explicit `name` argument, which has always worked for them.

The new exception is raised `from None`.  The AttributeError only
restates the attribute the message already names, and "During handling
of the above exception" would suggest coheriq hit a bug when the except
branch is in fact the designed path.

The decorator-side validation had no test, which is how the wrong type
survived; `test_nonstring_name` covers the constructor's name instead.

Assisted-by: Claude Opus 5

12 of 12 new or added lines in 2 files covered. (100.0%)

281 of 303 relevant lines covered (92.74%)

0.93 hits per line