Exceptions
Base classes
- All custom platform exceptions should inherit from AnchorCheckedException and AnchorRuntimeException.
- 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:
- Turn more custom-exceptions into friendly exceptions.
- Eliminate friendly-exceptions with blank
""messages (containing only a nested exception). Insist on messages.