Error formatting macro: pagetree: java.lang.NullPointerException

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

These are much less well considered! The primary reason for documenting them now is merely to make sure that nothing in Phase One blocks future development.

What's the Problem?

  • Exception throwers have the details and the context, and high level handlers have the policy. The right information is all available, but not all at the same time and place:
    • Throwers have to anticipate what handlers might need.
    • Handlers miss the time window to recover from the problem as it happens--the stack is already unwound.
  • Programmatic response to errors based on types is inflexible
    • Inheritance hierarchy baked in
    • Have to manufacture new types to drive dispatch 

Condition System

  • adopt matchure as general purpose matching strategy
    • update implementation to use protocols instead of multimethods
    • matching will work with class of plain Java exceptions
    • and also work with maplikeness of Clojure exceptions
  • How to prevent people from writing handlers that rely on debug-build information?
    • yes: warn users through documentation
    • no: parse matching forms and reject
    • no: give locals and bindings ugly "debug" names
  • possible approach
    • extend try/catch/finally with handle
    • handle takes two args: error and context
    • match on error to grab exceptions unwinding
    • then walk stack of registered handlers, matching on context
      • note that context is arbitrary object
      • it could be, or include, the error!
    • handler is fn of two args (error, context)
      • if not a fn, could be literal value for simple case
    • tools would be able to allow interactive restart, a la CL
    • note that this approach puts more responsibility on top and less on middle (when compared to CL)

...