Customizing Error-Message Handling

Use the SybMessageHandler interface to customize the way jConnect handles error messages generated by the server.

Implementing SybMessageHandler in your own class for handling error messages can provide the following benefits:

Universal error handling – error-handling logic can be placed in your error-message handler, instead of being repeated throughout your application.
Universal error logging – your error-message handler can contain the logic for handling all error logging.
Remapping of error-message severity, based on application requirements – your error-message handler can contain logic for recognizing specific error messages, and downgrading or upgrading their severity based on application considerations rather than the severity rating of the server. For example, during a cleanup operation that deletes old rows, you might want to downgrade the severity of a message that a row does not exist. However, you may want to upgrade the severity in other circumstances.

Note: Error-message handlers implementing the SybMessageHandler interface only receive server-generated messages; they do not handle messages generated by jConnect.

When jConnect receives an error message, it checks to see if a SybMessageHandler class has been registered for handling the message. If so, jConnect invokes the messageHandler method, which accepts a SQL exception as its argument. jConnect then processes the message based on what value is returned from messageHandler. The error-message handler can:

Return the SQL exception as is.
Return a null. As a result, jConnect ignores the message.
Create a SQL warning from a SQL exception, and return it. This results in the warning being added to the warning-message chain.
If the originating message is a SQL warning, messageHandler can evaluate the SQL warning as urgent, and create and return a SQL exception once the control is returned to jConnect.