Exception Handling

An exception represents an unexpected condition hindering a method from completion. In some cases, the exception is transient and you can retry it at a later time. In most cases, you must resolve the underlying cause of the exception to allow the API to complete successfully. In rare cases, the exception encountered corrupts the application state and may require you to terminate and restart the application.

• Base Exceptions
  A base exception class is defined as the super class for all external exceptions. Specific exceptions always inherit from the base exception. To enable you, the Object API developer, to write a standard exception handler, all external exceptions have an error code and a single error message. Furthermore, the exception may contain another exception as the cause.
• Exception Message Service
  You can implement an exception message service for resolving localized messages using error codes. The exception class uses the exception message service to load resource bundles and look up error messages based on an error code. You can use a default message provider, SUPExceptionMessageServiceImpl, or create a custom provider by implementing your own SUPExceptionMessageService.
• Service Registry
  The service registry holds implementation instances for various services used by the entity framework and applications. To allow you to use the exception message service, you must register the exception message service implementation represented by the SUPExceptionMessageService protocol with the service registry.
• Example Code for Handling Exceptions
  An example of registering your interface.
• Server-Side Exceptions
  A server-side exception occurs when a client tries to update or create a record and the Unwired Server throws an exception.
• Client-Side Exceptions
  Device applications are responsible for catching and handling exceptions thrown by the client object API. The HeaderDoc for the client object API lists the possible exceptions for the client.