This section describes how errors are handled. There are two
types of errors:
SCA runtime exceptions are those that signal problems in
the management of the execution of components, and in the
interaction with remote services. These might occur due to
network or configuration problems.
Business exceptions are those that are defined by the
programmer. They extend the PHP Exception class, and are thrown
and caught deliberately as part of the business logic.
Handling of Runtime exceptions
There are two types of SCA runtime exception:
SCA_RuntimeException - signals a problem found by or
perhaps occurring within the SCA runtime. This can be thrown for
a variety of reasons, many of which can occur regardless of
whether a connection is being made to a local or a remote service:
an error in one of the annotations within a component, a missing
WSDL or php file, and so on. In the case of Web services, an
SCA_RuntimeException can also be thrown if a SoapFault is
received from a remote Web service and the fault code in the
SoapFault indicates that a retry is unlikely to be successful.
SCA_ServiceUnavailableException - this is a subclass of
SCA_RuntimeException and signals a problem in connecting to or
using a remote service, but one which might succeed if retried.
In the case of Web services, this exception is thrown if a
SoapFault is received with a fault code that indicates that a
retry might be successful.
Handling of Business exceptions
Business exceptions may be defined and thrown by a component
in the normal way, regardless of whether the component has been
called locally or remotely. The SCA runtime does not catch
business exceptions that have been thrown by a component called
locally, so they will be returned to a caller in the normal way. If a
component has been called via a Web service, on the other hand, the
SCA runtime on the service providing end does catch business
exceptions, and will ensure these are passed back to the calling
end and re-thrown. Assuming that the calling end has a definition
of the exception (that is, is able to include a file containing the
PHP class defining the exception) the re-thrown exception will
contain the same details as the original, so that the
getLine() and
getFile() methods for example will contain
the location where the exception was thrown within the business
logic. The exception will be passed in the detail field of a soap
fault with a fault code of "Client".