Skip to end of metadata
Go to start of metadata

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 Contrib 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 Contrib 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.

Comparison with Sierra's Lazytest

  • Wants to pass as much information as possible from the point of a failure
  • Custom exception class written in Java takes Object as payload
  • expect macro throws that exception with a map as a payload containing assertion form, local bindings, dynamic bindings, file name, line number, and namespace
  1. Jan 04, 2011

    Please add links to other proposals, thanks. (In place, like the web)