Exception handling in ORBLink


Introduction to exception handling in ORBLink

This section describes how to customize the behavior of the ORB when a Lisp implementation of a CORBA interface signals an unexpected exception. This section does not discuss handling of two other kinds of exceptions:

The IDL encapsulation for exception handling in ORBLink is encapsulated in the following IDL:
module ORBLink {
  pseudo interface ORB : CORBA::ORB {
    enum break_policy_type {return,break};
    attribute break_policy_type break_policy;
 };
};

ORBLink server behavior on implementation exception

When a user's Lisp implementation of a CORBA interface signals a condition that is not a subtype of CORBA:userexception, or if it returns types that are not consistent with its IDL signature, one of two things occurs:

  1. A debugger break loop is entered on the server or
  2. A corba system exception is returned to the client.
Which of these occurs depends on the value of the break_policy attribute of corba:orb:

When (op:break_policy corba:orb) is :break

If the value of the break_policy attribute of corba:orb is :break, then option 1. above will be selected:
	(setf (op:break_policy corba:orb) :break)
A debugger break loop will be started and will offer the user at least the following options:

Debugger break loop options

Thus, the user can fix or modify, and then recompile, the implementation code before re-invoking it.

As such, it is useful important to understand the concepts of dynamic ORBLink server reconfiguration in CORBA server development.

When (op:break_policy corba:orb) is :return

If the value of the break_policy attribute of corba:orb is :return, option 2 is selected. A CORBA system exception will be returned to the invoking client.
	(setf (op:break_policy corba:orb) :return)

Default error handling

The default value of the break_policy attribute of corba:orb is:

:break
.

Default configuration failure modes

The invocation of a debugger by a server thread in response to an undeclared exception signalled by user code will not always result in a useful debugger output.

In particular, if the server is being run from a standard console, for example in a Unix tty shell, the created debugger will attempt to share input with the main Lisp listener which will result in user input being sent to the incorrect thread.

In consequence, when running an ORBLink server from a standard console, you should normally set the value of the break_policy attribute of corba:orb to :return.

In general, we have found the emacs/Lisp environment to be quite powerful for multi-threaded CORBA/ORBLink development.