# Exception handling in ORBLink

- Introduction
- Server behavior on implementation exception
- When `(op:break_policy corba:orb)` is `:break`
- When `(op:break_policy corba:orb)` is `:return`
- Default server behavior
- Default configuration failure modes

## 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:

- Customization of I/O exception handling is discussed in the section on connection management.
- Invocation of a CORBA operation on a Lisp client-side proxy may result in a condition being signalled to the client. The behavior of the program in this case can be customized via the standard Common Lisp `handler-case` form and is outside the scope of this document.

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

- Returning a corba SYSTEM EXCEPTION to the client
- Reinvoking the function that signalled the condition.

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.