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 stops 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.
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).