BioMOBY

The following is a list describing the exception conditions, such as overflows and errors resulting from incorrect or unmatched data, which are generated during program execution. The error codes are compatible with the LSAE specification. *New (BioMOBY specific) error types not included in LSAE specification

Exception codes dealing with analysis data
Code	Name	Description
200	UNKNOWN_NAME	Setting input data under a non-existing name, or asking for a result using an unknown name
201	INPUTS_INVALID	Input data are invalid; they do not match with their definitions, or with their dependency conditions (Taken from LSAE, in BioMOBY this means a generic invalid input error. Other specific invalid input errors listed below)
202	INPUT_NOT_ACCEPTED	Used when a client tries to send input data to a job created in a previous call but the server does not any more accept input data
221*	INPUT_REQUIRED_PARAMETER	Service require parameter X
222*	INPUT_INCORRECT_PARAMETER	Incorrect parameter X
223*	INPUT_INCORRECT_SIMPLE	Incorrect input in simple article
224*	INPUT_INCORRECT_SIMPLENB	Service requires two or more simple articles
225*	INPUT_INCORRECT_COLLECTION	Incorrect input in collection article
226*	INPUT_EMPTY_OBJECT	Empty input object
227*	INPUT_INCORRECT_NAMESPACE	Incorrect Namespace in the input object

Exception codes dealing with analysis execution
Code	Name	Description
300	NOT_RUNNABLE	The same job has already been executed, or the data that had been set previously do not exist or are not accessible anymore. Life Sciences Analysis Engine Adopted Specification
301	NOT_RUNNING	A job has not yet been started. Note that this exception is not raised when the job has been already finished.
302	NOT_TERMINATED	A job is not interruptible for some reason.

Error codes dealing with analysis metadata
Code	Name	Description
400	NO_METADATA_AVAILABLE	There are no metadata available

Error codes dealing with notification
Code	Name	Description
500	PROTOCOLS_UNACCEPTED	Used when a server does not agree on using any of the proposed notification protocols

General error codes
Code	Name	Description
600	INTERNAL_PROCESSING_ERROR	A generic catch-all for errors not specifically mentioned elsewhere in this list
601	COMMUNICATION_FAILURE	A generic network failure
602	UNKNOWN_STATE	Used when a network call expects to find an existing state but failed. An example is an unknown handler representing a Job (unknown Job_ID, typical for WebServices platform)
603	NOT_IMPLEMENTED	A requested method is not implemented. Note that the method in question must exist (otherwise it may be caught already by the underlying protocol and reported differently) - but it has no implementation

Service intrinsic exceptions
Code	Name	Description
700	OK	Service execution was correct(This is a placeholder error code to allow the service to provide a formatted information block in the response)
701	SERVICE_INTERNAL_ERROR	Specific errors from the BioMOBY service(I.e. from Blast 'Check the sequence format; it does not seem to be a nucleotide/Amino acid sequence')

Specification (API v0.86) changes

In addition to the above (3) section, the following specification changes are proposed:

1. FROM: In the case of Retrieve calls, failure will be silent and an empty object of the associated output type will be returned. TO:In the case of Retrieve calls an error, failure should be silent raise an exception and an empty object of the associated output type mobyData block with the appropriate queryID will be returned. Comments to this change: Exception rising is optional, but should be recommended. The wording in the original API was wrong - the object is not empty, the mobyData block is empty.
2. FROM: There MUST BE as many mobyData response elements as there were mobyData input elements (if a service can not respond to a specific query for whatever reason, this element may be empty!) TO: There MUST BE as many mobyData response elements as there were mobyData input elements (if a service can not respond to a specific query for whatever reason, this element may be empty, but an exception could be raised to explain why) Comments to this change: Exception rising is optional. The service provider could choose to report the failure or not, but still has to return an empty element.
3. FROM: The serviceNotes block is only loosely defined in this version of the API, and is currently meant to contain human-readable free text. serviceNotes are optional. TO: The serviceNotes block is only loosely defined has been changed to support exception reporting in this version of the API. In addition to the mobyException element for exception reporting, a Notes child element and is currently meant to contain human-readable free text. serviceNotes are optional. Comments to this change: The original bioMOBY specification states that the serviceNotes element should contain human-readable text. With the addition of an structured XML mobyException element, and to avoid mixed free-text and XML content in serviceNotes, a new Notes child element is added under serviceNotes to preserve its previous functionality.