Allow specifying error type to be raised by decompose

[lillian542]

Context:
As the decompose transform is used in various contexts, it would be nice to specify the error type that should be raised if its not possible to get a suitable decomposition for one of the operators (i.e. devices raise DeviceError, transforms and gradients raise DecompositionUndefinedError, catalyst raises CompileError)

Description of the Change:
An error kwarg is added to decompose and its helper function _operator_decomposition_gen so that the error type can be specified. It continues to default to DeviceError

Benefits:
We don't have to duplicate many lines of code to get an identical function with a different error type

Possible Drawbacks:
More kwargs

Related GitHub Issues:
N/A

Related Shortcut Stories:
[sc-61450]

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.md with:

• A one-to-two sentence description of the change. You may include a small working example for new features.
• A link back to this PR.
• Your name (or GitHub username) in the contributors section.

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.md with:

• A one-to-two sentence description of the change. You may include a small working example for new features.
• A link back to this PR.
• Your name (or GitHub username) in the contributors section.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.68%. Comparing base (ab8d739) to head (b64174c).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5669      +/-   ##
==========================================
- Coverage   99.69%   99.68%   -0.02%     
==========================================
  Files         412      412              
  Lines       38663    38367     -296     
==========================================
- Hits        38545    38245     -300     
- Misses        118      122       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lillian542]

[sc-61450]

[dwierichs]

The change looks good to me, thanks @lillian542! 🎉

Would be good to update the Args: section as the comment details.
Also, do we want a basic test that asserts the error kwarg being used correctly?
And a changelog entry? 🤔

[trbromley]

Thanks @lillian542!

it would be nice to specify the error type that should be raised

Are you able to speak more towards that motivation? I guess this is needed for Catalyst integration, but I'm just curious to understand more.

[lillian542]

Also, do we want a basic test that asserts the error kwarg being used correctly?
And a changelog entry? 🤔

@dwierichs - why yes. Yes we do want those things 🙈

[lillian542]

Are you able to speak more towards that motivation? I guess this is needed for Catalyst integration, but I'm just curious to understand more.

@trbromley - this function was originally used only in preprocessing for standard devices (which we want to raise a DeviceError if it gets an operation it can't use or decompose).

As of this week, it's also used in transforms, where no device is present, and it would be better to raise the original DecompositionUndefinedError. For catalyst, the issue that we hit in decompose is whether or not it can be compiled via qjit for the given device, and everything in that part of the pipe line raises a CompileError.

So the motivation is to keep error types consistent with what process is failing, even though at the end of the day they all come down to a DecompositionUndefinedError arising in different contexts.

An alternative would be to always use DecompositionUndefinedError. That would be accurate, but inconvenient in try-except blocks where we would like to, for example, try to run preprocessing and have special handling if a DeviceError is raised.

[dwierichs]

Thanks @lillian542
Just 1.5 comments regarding the docstring.