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
- 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 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)
;; simple degenerate example
;; error matcher is IOException (could be arbitrary match)
;; context is :io (could be arbitrary match)
;; handler is "<NO DATA>" (could be arbitrary fn)
(defn top 
(with-handler :io "<NO DATA>"
(defn middle 
(handle IOException :io)))
(defn bottom 
Better Java Unification
ISnapshot protocol identifies Java objects that can be "immutable data-ized"
- protocol extends to throwable
- other possible cool uses
- dynamic codegen of nonreflective code a la
- extend condition system to call through
ISnapshot where available
- get power of matching with plain ol' Java exceptions!
- simplify REPL and reporting code
- all exceptions can now be treated as data, from Java or from Clojure
- would snaphsot need to be memoized ??
- simple LRU might be good enough
- or could use a weak map keyed by base object
- do exceptions consume any native resources?
- if unification with Java was good enough, could we drop the Clojure-specific exceptions?
- unlikely – bottom needs to be separable
IPersistentMap were protocols...