Edit me


Base classes

  1. All custom platform exceptions should inherit from AnchorCheckedException and AnchorRuntimeException.
  2. Two additional abstract classes AnchorFriendlyCheckedException and AnchorFriendlyRuntimeException indicate exceptions which are guaranteed to have either:
    • either a user-friendly error message describing whats going wrong.
    • simply nest another exception, with a blank "" message.

Design contract of throwing the exceptions

By throwing a friendly exception, the developer promises that simply displaying this exception (and the messages of its nested causes) are sufficient to explain the error to the end-user.

By throwing a non-friendly, this implies that more information (e.g. a stack trace) should be shown to the user, so they can figure out what went wrong.

Longer-term progression towards friendly-exceptions

As stack-traces are ugly to display to the end-user, it is planned over time:

  1. Turn more custom-exceptions into friendly exceptions.
  2. Eliminate friendly-exceptions with blank "" messages (containing only a nested exception). Insist on messages.
Tags: architecture