Error formatting macro: pagetree: java.lang.NullPointerException
Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

Comparison with McGranaghan's clj-stacktrace

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.

Comparison with Raek's proposal

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:

  • the use of pattern matching makes it easy to work with exceptions, maps, or both
  • the addition of ISnapshot will 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.

Comparison with Gilardi's condition

  • uses gen-class to make one Condition to rule them all
    • current plan is to do something similar to this
  • uses dynamic binding to keep track of current error
    • plan is to unify more closely with JVM exceptions instead
  • uses case construct for selecting handlers
    • hope to provide a more general mechanism for communicating between top/middle/bottom
    • should be able to write condition in terms of the new thing, if desired
  • implementation note: uses atom for one-time init
    • now we can use promises for this instead

Comparison with Chouser's error-kit

error-kit does not try to unify with host exceptions. This gives it the freedom to do several things:

  • use a special singleton "control exception" for flow control
  • make unnamed errors using proxy instead of gen-class
  • define names via deferror that are not meaningful in Java exception terms
  • provide a special callout :unhandled for 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.

Labels: