clj-stacktrace parses exceptions into data, and then provides some creature comforts for printing, colorizing, etc. The parsing part is a key element of the new plan as well, and I hope to adopt a significant fraction of the clj-stacktrace naming conventions and code.
The "throwable maps" idea is very similar to what I am proposing here. The other half of Raek's proposal works to split host integration and arbitrary dispatch. I hope to avoid this split. Instead:
ISnapshotwill make pattern matching even better: plain and rich exceptions almost entirely unified
I don't think the performance concerns that drive the protocol/multimethod split apply to exception handling. Exception handling is exceptional, and should be able to afford (slightly) slower dispatch.
gen-classto make one Condition to rule them all
error-kit does not try to unify with host exceptions. This gives it the freedom to do several things:
deferrorthat are not meaningful in Java exception terms
:unhandledfor dealing with the boundary with JVM exceptions
Since I am hoping to unify better with Java exceptions, none of these design options are open or relevant.