Cleaner practices: Cataloguing the menagerie of inlined throw strings.

[Hamiltonian-Action]

Issue

This is not directly a user-facing problem (during correct usage) but rather endemic to the codebase itself. There appears to be some rather prolific usage of inlined throw strings which could benefit from additional structuring, be it enhanced formatting, centralisation into a single file, or establishing a consistent ordering -- this last one need not be considered too thoroughly if the number of potential throwing scenarios is not too large.

Solution

I would propose the introduction of a dedicated file, say throws.jl , and shifting the various strings currently in use towards it, either gradually as different sections get touch-up work or via some dedicated effort. Furthermore, there is no need to explicitly specify where the error originates from in the string itself, since the stack trace will clearly indicate so in lieu.

Example

In QuantumClifford.jl, the function comm! contains the following:

nqubits(l) == nqubits(r) || throw(DimensionMismatch(lazy"The number of qubits of the input Pauli operator and the input tableau have to match in `comm!`"))

Whereas in mul_leftright.jl, the functions mul_left! and mul_right! contain:

nqubits(l)==nqubits(r) || throw(DimensionMismatch("The two Pauli operators should have the same length!"))

Under this proposal, the following definition would be provided in the dedicated file:

const THROW_NQUBITS::LazyString = "Unable to perform the requested operation due to encountering a mismatch between the number of qubits in the provided arguments."

Whilst the aforementioned functions will simply read:

nqubits(l) == nqubits(r) || throw(DimensionMismatch(THROW_NQUBITS))

[Krastanov]

Making a global constant string that you can reuse sounds good. No need to mark it as lazy if it does not use interpolation. And for those that use interpolation you would need a function anyway, so again no need to mark it as lazy.

[niranjannagumalli]

Hey @Krastanov and @Hamiltonian-Action
I've submitted a PR which solves this issue. Could y'all please have a look and provide me any suggestions if any?
Thanks in advance.