Skip to end of metadata
Go to start of metadata

This proposal is subsumed under the first phase of Error Handling


  • Provide useful stacktraces to end-users
  • Provide stacktraces-as-data to library developers


Stacktrace handling can be divided into three parts: collecting and parsing the exception data, filtering/transforming that data as appropriate for Clojure, and then rendering that data according to some design.

To facilitate steps 2 and 3 for Clojure itself and also for other library developers, we propose to first parse exceptions into Clojure data structures and to provide this data as input to the filtering/transforming and rendering phases.

The data-based approach is used by clj-stacktrace.

clj-stactrace, clojure.repl, and clojure.stacktrace all have different takes on the formatting aspect of stacktrace presentation.


  • Why is :annon-fn three-valued (true, false, and missing)?
  • Is it possible to get full paths instead of filenames under the :file key?
  • Default display format for stacktraces for script and REPL exceptions
  • Details of exception data representation, especially strings vs. non-strings and how to represent different types of trace elements like methods, def'd fns, and closures
    • SDH: I think names of classes, methods, etc. should be symbols (as opposed to strings). Haven't looked to see what current impls do so this may be moot.