Home |
Previous Page | Next Page Database Access > Handling Exceptions and Events > Event-Handling Mechanisms >
If no callback is registered for a particular event, the DataBlade API uses
its default behavior when this event occurs. The default event handling
depends on whether the event occurs in a C UDR or in a client LIBMI application.
Default
Behavior in a C UDR (Server)
If an exception occurs during the execution of the UDR and
the UDR does not register any
callback to handle this event, the DataBlade API takes one of the following default
actions.
| Exception Type |
Default Behavior |
| MI_Exception |
An
unhandled MI_MESSAGE exception does not halt
execution of the current statement. The DataBlade API passes the warning to
the client application, and processing continues at the next statement
of the UDR.
An
unhandled MI_EXCEPTION exception aborts execution of the current
statement in the UDR. The DataBlade API returns control
to the calling module. |
| MI_Xact_State_Change |
When received in a UDR, an MI_Xact_State_Change
exception is treated the same as an MI_EVENT_END_XACT event. |
If
a UDR does not register a callback for the MI_Exception
event whose exception level is MI_EXCEPTION (a
runtime error), the DataBlade API aborts the UDR and returns control
to the calling module, which might have been either of the following modules:
- A client application that called the UDR in
an SQL statement
- Another UDR that called
the UDR that encountered the runtime error
The calling module might have a registered callback (or some
other method) to handle the exception. To prevent database runtime
errors from aborting a UDR, use the mi_register_callback( ) function
to register callbacks in the UDR. For more information,
see Exceptions in a C UDR (Server).
Important:
Programming
errors do not cause execution of callbacks. If a
UDR contains
a serious programming error (such as a segmentation fault), execution
jumps out of the routine and back to the routine manager. The routine
manager attempts to make an entry in the database server message
log file (
online.log by default).
Default
Behavior in Client LIBMI Applications
If an exception occurs during the execution of a client LIBMI application
and the application does not register any
callback to handle the exception, the client LIBMI takes
one of the following default actions.
| Exception Type |
Default Behavior |
| MI_Exception |
The client LIBMI executes the system-default
callback. The mi_default_callback( ) function
implements this system-default callback.
An unhandled
MI_MESSAGE does not halt execution of the current
statement. The DataBlade API passes the warning to the client LIBMI application,
and processing continues at the next statement of this client application.
An
unhandled MI_EXCEPTION aborts execution of the current statement
in the client LIBMI application. The DataBlade API passes the error to
the client LIBMI application and returns control to this client
application. |
| MI_Xact_State_Change |
An unhandled MI_Xact_State_Change does not halt
execution of the current statement. Processing continues at the
next statement of the client LIBMI application. |
| MI_Client_Library_Error |
The client LIBMI executes the system-default
callback. The mi_default_callback( ) function
implements this system-default callback. |
UNIX/Linux Only
On UNIX or Linux, the system-default callback causes
the client LIBMI application to send an
error or warning message to stderr in response
to an unhandled exception.
End of UNIX/Linux Only
Windows Only
On Windows, the system-default callback causes the client LIBMI to
display an error or warning message in a Windows message box
in response to an unhandled exception.
End of Windows Only
To prevent the execution of the system-default callback, use
the mi_register_callback( ) function
to register callbacks in the client LIBMI application. For
more information, see Exceptions
in a Client LIBMI Application (Client) and Client LIBMI Errors.
Home |
[ Top of Page | Previous Page | Next Page | Contents |
Index ]