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.