Improve exception expressiveness

[nelimee]

Is your feature request related to a problem? Please describe. For the moment, the code base only include one exception, TQECException, that is raised with a descriptive error message whenever an exception need to be raised. It might be beneficial to split that unique exception into several more expressive ones.

What is you opinion on that? If you agree, what should be, in your opinion, the rule to decide whether a new exception inheriting from TQECException should be included or an existing generic exception (such as TQECException) should be used?

[Gistbatch]

I suggest that we have exceptions for multiple situations. Parsing the description string is easy for a user but not helpful when catching specific exceptions programmatically.

Some possible use cases:

• InvalidCodeException: The user has specified an invalid error correction code or something similar
• FormatException: Exceptions when switching between libraries occur, e.g., TQEC frontend, stim, cirq, collada ...
• BrokenAssumption: If one of the assumptions throughout the code is not fulfilled, e.g. midline cannot be computed

[purva-thakre]

If no one is working on this, can the issue be assigned to me?

[purva-thakre]

@nelimee For all the newer exceptions that need to be defined, is TQECException expected to be the base class for all of them?

https://github.com/tqec/tqec/blob/f8ebe11d68eda66345568cf48a8e14f8a59686fb/src/tqec/circuit/schedule/exception.py#L4-L7

I do prefer what Gistbatch's comment says.

[nelimee]

@nelimee For all the newer exceptions that need to be defined, is TQECException expected to be the base class for all of them?

https://github.com/tqec/tqec/blob/f8ebe11d68eda66345568cf48a8e14f8a59686fb/src/tqec/circuit/schedule/exception.py#L4-L7

I do prefer what Gistbatch's comment says.

I would say that all exceptions raised by tqec (except maybe the NotImplementedError) should inherit from one unique exception, to allow a try/catch that will catch any exception raised by tqec.

@Gistbatch comment and the above can both coexist, and I think that is what we should target.

[purva-thakre]

except maybe the NotImplementedError

what's the motivation behind this? The official inheritance hierarchy shows NotImplementedError being derived from the base exception, which is TQECException in our case.

[nelimee]

except maybe the NotImplementedError

what's the motivation behind this? The official inheritance hierarchy shows NotImplementedError being derived from the base exception, which is TQECException in our case.

BaseException is a standard library Python class. My message was unclear, I wanted to say that, ideally:

• all exceptions raised directly by tqec should inherit from a base class from the tqec package, which is TQECException at the moment,
• the unique potential exception I see to the above rule is NotImplementedError, which might be better kept as-is.

The rationale behind this is the following:

• if a tqec-exception (i.e., an exception in the inheritance hierarchy of TQECException) is raised, that should always mean that the user misused tqec. In practice we will have bugs, and so that might not be the case every time, but I think we should target that.
• if any other exception is raised, that is definitely a bug in tqec (with the potential exception of NotImplementedError that I would not qualify as a bug).

Also, in practice, exceptions are never used for control-flow in tqec (and should never be in my opinion). That means that all exception raised are basically fatal and will interrupt the program. That might be an argument for not differentiating exceptions.

[purva-thakre]

For anyone interested in working on this, see #626, which has a detailed discussion along with additional resources in the PR description. The diff in the PR is a first pass attempt. However, the code base has changed a lot since then. You should start fresh rather than cherry-picking commits from my older PR.