Error Handling¶

This page is only concerned with runtime errors. Program errors are not considered here.

Scope of Error Handling¶

Sources of Runtime Errors¶

• Client-supplied event handlers
• Connectors
  • When receiving notifications
  • When decoding notifications
  • When sending notifications
• Converters
  • When converting domain-object -> wire-data
  • When converting wire-data -> domain-object

Error Handling Locations¶

• In Connectors (via client-supplied policy)
  • Can handle Connector errors
  • Can handle Converter errors
• In Processors (via client-supplied policy)
  • Can handle errors in client-supplied event handlers
• In callbacks to client code
  • Can handle Connector errors
  • Can handle Converter errors
  • Can handle errors in client-supplied event handlers

Implementation Concept¶

• Rationale for additional error handling mechnisms:
  • Exceptions need to be communicated asychronously
  • Exceptions need to be communicated across thread boundaries
• Tree-like structure of callbacks attached to active objects
  • Exceptions are communicated to callbacks bottom-up
  • Policies are communicated to backend objects top-down
  • Default implementation of callbacks propagate exceptions to parent callbacks
  • Propagated callbacks are dispatched to client code
  • If errors are handled locally, we still want to notify client code but transform the error into some kind of general warning or situation

Error Transport Mechanisms¶

• Stack unwinding
  • Only applicable for pull-path
  • Can transport Connector errors
  • Can transport Converter errors
• Callback invocation from local error handling policy
  • Can handle Connector errors
  • Can handle Converter errors
  • Can handle errors in client-supplied event handlers

Error Handling Policies¶

• Ignore the error and continue
• Log the error and continue
  • With backtrace (like "debug" mode)?
  • Without backtrace, maybe don't repeat log message (like "production" mode)?
• Terminate the whole process (i.e. exit(1))