Problem Statement
Clojure's REPL is capable of paramterizing almost every aspect of its functionality, including how uncaught exceptions are printed. In the current implementation, these customization hooks are passed in as arguments and closed over, meaning that they cannot be changed once the REPL is started.
Many development tools want to override how the REPL handles uncaught errors. Examples of useful customizations include (but are not limited to):
- Formatted exception messages (including whitespace and ANSI coloring)
- Alternative representations for certain types of exceptions (e.g, Spec errors)
- Dropping into a graphical interaction mode to better inspect ex-data.
Currently, this type of customization must be applied before a REPL is started, meaning that changing how a REPL displays errors requires support from (or plugins to) a third-party tool such as Boot or Leiningen.
Alternatives
<BR/>
1. Take no action.
Third-party tool support is required to create customized exception handling in the REPL. Tools have different techniques for doing this:
- nREPL can intercept the exception on the wire and passes it through middleware
- Leiningen plugins alter the root binding of {{clojure.main/repl-caught}}.
- Boot allows users to build a task to invoke {{clojure.main/repl}} with the desired arguments.
Users will continue to select one of these according to their tooling preferences.
Benefits:
1. No effort or changes to the existing code.
Tradeoffs:
1. Tools will continue to implement their own diverse, sometimes hacky techniques for printing custom exceptions.
2. Any library intended to provide alternative exception handling will be tied to a specific launcher tool.
- Make the REPL exception handler dynamically rebindable
If the REPL exception handler were a dynamic, thread-local var, users and libraries could change the behavior of the currently running REPL.
Benefits:
1. Users and libraries can freely override how exceptions are printed, regardless of how Clojure was launched.
2. Fully backwards compatible with existing tools.
Tradeoffs:
1. It will be possible for library authors to provide "bad" or poorly reasoned error printers. This is still possible with launch tools, but the barrier of entry is even lower with libraries.
The attached patch implements this option.
- Encourage users to start new REPLs instead
In many Clojure environments, it's possible to explicitly launch a REPL from within another REPL. This sub-REPL could have the desired :caught hook.
Benefits:
1. No effort or changes to the existing code.
2. "Functionally pure", and in alignment with the evident design of the current REPL.
Tradeoffs:
1. There is a non-trivial subset of Clojure developers who do not know exactly how REPLs work. They are likely to be confused or subject to increased cognitive load. Insofar as this set of beginner/intermediate developers are precisely who enhanced error messages are meant to help in the first place, this solution is counterproductive.
2. For better or for worse, many existing and widely used tools do not support this. This does not work at all in nREPL, for example. However, even the simplest command-line REPLs behavior would change for the worse; sending a EOF (accidentally or otherwise) would always kill the sub-REPL with no feedback as to what just happened.
