Have custom errors specific for protocols

[ijpulidos]

In OpenFreeEnergy/feflow#96 we encountered the case where it could be useful to have custom errors for protocols. For example, there are some limitations on the methodologies themselves that a protocol uses (such as hybrid topology generation not supporting ring breaking transformations), and also things that are just not allowed by the tooling, such as charge changing transformations that change more than one formal charge unit.

The idea being that we would like to have a shared/standard custom error that protocol authors could use. Is this something that we would like to have in gufe?

[dotsdl]

I think a standard Exception taxonomy for Protocols makes sense, and would be a helpful addition. The aim would be to catalog failure modes that are generally common across many alchemical Protocols, and provide Exception classes that could be used directly or further subclassed.

This is also somewhat related to #392.

[jthorton]

Some ideas for generic base protocol errors which could be subclassed or used by protocol developers the idea here is to make it clear at which stage the protocol has failed:

• ProtocolValidationError: this should be raised when validating the inputs to the protocol and signifies the calculation has not yet started.
• ProtocolSetupError: this should be raised if we encounter an issue running the setup unit for this protocol and should make it clear that setup has failed and that the protocol has not yet reached the production stage of the calculation.
• ProtocolExecutionError: this should be raised if we hit an issue in the running of the protocol.
• ProtocolAnalysisError: this should be raised if we hit an issue with generating any post-calculation analysis.

I think the examples, such as ring breaking or charge changes involving more than one formal charge unit, not being supported by the hybrid topology protocol would then be raised as a ProtocolValidationErrors.

@hannahbaumann, @IAlibay @ijpulidos as protocol developers it would be great to get your input here on any other common failure modes that we could have a generic protocol error for and if these current errors seem reasonable.