Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<h3>Problems</h3>

<ul>
	<li>platform uses types for dispatch
	<ul>
		<li>only error handling is platform error handling</li>
	</ul>
	</li>
	<li>want to carry data payloads
	<ul>
		<li>platform exceptions don't</li>
	</ul>
	</li>
	<li>need out-of-band communication
	<ul>
		<li>for both ordinary and exceptional things!
		<ul>
			<li>exceptional things are ordinary during development</li>
		</ul>
		</li>
		<li>and ways to discover the oob mechanisms</li>
	</ul>
	</li>
	<li>can't deal with exception at point it happens
	<ul>
		<li>can't resume</li>
	</ul>
	</li>
	<li>cannot manipulate exceptions as data</li>
</ul>

<h3>Symptoms</h3>

<ul>
	<li>new application problems beget new types
	<ul>
		<li>types are heavy</li>
		<li>why don’t people use an existing type?
		<ul>
			<li>want to branch on it (flow control)</li>
			<li>habit</li>
			<li>carry data</li>
		</ul>
		</li>
	</ul>
	</li>
	<li>new exception types lead to
	<ul>
		<li>gen-class (+ precompilation)</li>
		<li>Java classes in Clojure projects</li>
	</ul>
	</li>
	<li>use big things to solve small problems
	<ul>
		<li>condition library (e.g. <a href="https://github.com/clojure/clojure-contrib/blob/master/modules/condition/src/examples/clojure/examples/condition.clj">Contrib Condition</a>) when all you want is data</li>
		<li>exceptions when all you want is control flow
		<ul>
			<li>idiomatic on many JVM languages</li>
			<li>don't have composite returns or dynamic binding</li>
		</ul>
		</li>
	</ul>
	</li>
	<li>can't troubleshoot problems
	<ul>
		<li>info is gone when call stack unwinds</li>
	</ul>
	</li>
</ul>

<h3>Example Use Cases</h3>

<ul>
	<li>communicate ordinary things
	<ul>
		<li>recover from I/O failure</li>
		<li>convey detailed information for reporting in test framework</li>
	</ul>
	</li>
	<li>communicate exceptional things
	<ul>
		<li>program bugs</li>
		<li>platform and hardware failures</li>
	</ul>
	</li>
	<li>jump to debugger based on situation</li>
	<li>add information to an exception
	<ul>
		<li>e.g. Alan's adorning macro arity example</li>
	</ul>
	</li>
	<li>troubleshoot build failure that is only on Hudson</li>
</ul>

<h3>Constraints</h3>

<ul>
	<li>dispatch should be fast
	<ul>
		<li>where exceptions are used for exceptional things, performance is not an issue</li>
	</ul>
	</li>
	<li>error handling should unify at bottom with Java</li>
	<li>neither ordinary nor exceptional things should have to pollute API for fns that don't care or can't respond
	<ul>
		<li>pay for what you need</li>
	</ul>
	</li>
</ul>

<h3>An even-more modest proposal</h3>

I think we should implement

<ul>
	<li>education on dynamic bindings</li>
	<li>bindable <code>*assertion-handler*</code></li>
	<li>(maybe) clj-stacktrace-like data-ification fns for exceptions</li>
	<li>(maybe) data-carrying <code>*RuntimeException*</code> subclass</li>
</ul>

All of these ideas, and several others not chosen, are documented below.

<h3>Some approaches</h3>

Table of some approaches and how they address the problems above. Approaches described in more detail below. Some of the approaches are deliberately crazy for contrast (wonder if we will agree on which ones).

<table class="confluenceTable"><tbody>
<tr>
<th class="confluenceTh"> Approach </th>
<th class="confluenceTh"> Type Dispatch </th>
<th class="confluenceTh"> Data Payloads </th>
<th class="confluenceTh"> Out-of-band Communication </th>
<th class="confluenceTh"> Action at Point of Exception </th>
<th class="confluenceTh"> Exceptions as Data </th>
<th class="confluenceTh"> Notes </th>
</tr>
<tr>
<td class="confluenceTd"> education on dynamic binding </td>
<td class="confluenceTd"> solves </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> solves </td>
<td class="confluenceTd"> could solve </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> </td>
</tr>
<tr>
<td class="confluenceTd"> clj-stacktrace </td>
<td class="confluenceTd"> should unify with dataification of exceptions, if any </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> partially solves for non-Clojure types </td>
<td class="confluenceTd"> </td>
</tr>
<tr>
<td class="confluenceTd"> ad hoc conditions </td>
<td class="confluenceTd"> worsens </td>
<td class="confluenceTd"> could solve </td>
<td class="confluenceTd"> worsens </td>
<td class="confluenceTd"> solves </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> worsens = replaces general mechanism with more specialized one </td>
</tr>
<tr>
<td class="confluenceTd"> pattern-matching conditions </td>
<td class="confluenceTd"> ? </td>
<td class="confluenceTd"> could solve </td>
<td class="confluenceTd"> worsens </td>
<td class="confluenceTd"> solves </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> worsens = replaces general mechanism with more specialized one </td>
</tr>
<tr>
<td class="confluenceTd"> data-carrying exception </td>
<td class="confluenceTd"> could support pattern matching </td>
<td class="confluenceTd"> solves </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> solves for Clojure types </td>
<td class="confluenceTd"> </td>
</tr>
<tr>
<td class="confluenceTd"> enrich exceptions with local context </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> enhanced </td>
<td class="confluenceTd"> for errors only </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> enhanced </td>
<td class="confluenceTd"> yuck: makes everybody pay for debug time support </td>
</tr>
<tr>
<td class="confluenceTd"> bindable test/assertion handler </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> for assertions </td>
<td class="confluenceTd"> for assertions </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> </td>
</tr>
<tr>
<td class="confluenceTd"> bindable throw handler </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> for Clojure exceptions </td>
<td class="confluenceTd"> for Clojure exceptions </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> </td>
</tr>
<tr>
<td class="confluenceTd"> platform-based handler </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> solves </td>
<td class="confluenceTd"> solves </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> does it exist? </td>
</tr>
<tr>
<td class="confluenceTd"> bindable edge handler </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> tries and fails </td>
<td class="confluenceTd"> tries and fails </td>
<td class="confluenceTd"> could help </td>
<td class="confluenceTd"> yuck: perf, asymmetry, doesn't accomplish desired goal </td>
</tr>
<tr>
<td class="confluenceTd"> wrap java exceptions </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> orthogonal </td>
<td class="confluenceTd"> at Clojure boundary </td>
<td class="confluenceTd"> n/a </td>
<td class="confluenceTd"> could support </td>
<td class="confluenceTd"> yuck; terrible perf, terrible asymmetry, or both </td>
</tr>
<tr>
<td class="confluenceTd"> &quot;modest proposal&quot; above </td>
<td class="confluenceTd"> solves  </td>
<td class="confluenceTd"> solves  </td>
<td class="confluenceTd"> solves, with extra goodness for debug </td>
<td class="confluenceTd"> solves, with extra goodness for debug </td>
<td class="confluenceTd"> solves </td>
<td class="confluenceTd"> what's not to like? see bottom of this page... </td>
</tr>
</tbody></table>

<h3>Education on Dynamic Binding</h3>

Document dynamic binding as the &quot;Clojure Way&quot; to do out-of-band-control flow that is often done via exceptions on other JVM languages.

<ul>
	<li>find likely place within Clojure or Contrib and implement examplar</li>
	<li>write docs and tutorial</li>
	<li>add &quot;control flow&quot; link from exception handling parts of Clojure docs</li>
</ul>

<h3><a href="https://github.com/mmcgrana/clj-stacktrace">clj-stacktrace</a></h3>

<ul>
	<li>define a standard vocabulary for data-izing the information in a clojure exception</li>
	<li>package in fns
	<ul>
		<li>do not call these fns automatically</li>
		<li>maybe provide REPL helpers that do</li>
	</ul>
	</li>
	<li>other parts of clj-stactkrace (color printing etc.) should remain tool features</li>
	<li>open questions
	<ul>
		<li>what do the REPL fns look like?</li>
		<li>might start with the data and wait to see how they get used</li>
	</ul>
	</li>
</ul>

<h3>Ad hoc conditions</h3>

E.g. <a href="https://github.com/clojure/clojure-contrib/blob/master/modules/condition/src/examples/clojure/examples/condition.clj">Contrib Condition</a> or <a href="https://github.com/clojure/clojure-contrib/blob/master/modules/error-kit/src/main/clojure/clojure/contrib/error_kit.clj">Contrib Error-Kit</a>.

<ul>
	<li>could unify with Java exceptions, or not</li>
	<li>could include data-carrying exception, or not</li>
</ul>

Not carrying this idea forward at this point.

<h3>Pattern Matching Conditions</h3>

Pattern matching (a la <a href="https://github.com/dcolthorp/matchure">Matchure</a>), plus exceptions as data, plus dynamic binding.

Not carrying this idea forward at this point.

<h3>Data-carrying exception</h3>

Single exception type that can carry data, allowing clojure data tools to be used to process exceptions.

<ul>
	<li>subclass RuntimeException?
	<ul>
		<li>or one new type for each family (error, runtime, assertion?)</li>
	</ul>
	</li>
	<li>unify keys with clj-stackrace or equivalent if that is also done</li>
	<li>open questions
	<ul>
		<li>what are the programmatic (non-interactive) uses of this data?</li>
	</ul>
	</li>
</ul>

<h3>Enrich exceptions with local context</h3>

<ul>
	<li>add locals, bindings, kitchen sink to exceptions</li>
	<li>could be debug-only</li>
	<li>could be tied to throw, or only to assertions</li>
</ul>

<h3>Bindable test/assertion handler</h3>

<ul>
	<li>Create a bindable <code>*assertion-handler*</code> that can run with full context at the point an assertion fails
	<ul>
		<li>application of dynamic binding to the problem &quot;Assertion fails where I can't get a debugger&quot; (e.g. Hudson)</li>
		<li>default behavior is to raise the error</li>
		<li>facilitates use of assertion as the primary/only mechanism for tests, instead of separate fns like <code>is</code></li>
	</ul>
	</li>
	<li>implicitly debug-only through tie to assertions
	<ul>
		<li>once assertions are debug-only, anyway</li>
	</ul>
	</li>
	<li>maybe assertions should never have been exceptions in the first place
	<ul>
		<li>more of a use case for handlers than for exceptions</li>
		<li>unexpected errors are, ironically, expected errors during development</li>
	</ul>
	</li>
	<li>making assertions handler-based solves my &quot;assertions are backwards&quot; rant
	<ul>
		<li>handler can do anything it needs to with local context</li>
	</ul>
	</li>
	<li>also decouples the Java enablement issue
	<ul>
		<li>clojure binding controls initial reaction</li>
		<li>Java -ea flag controls fallback behavior (assert or do nothing)</li>
	</ul>
	</li>
	<li>open questions
	<ul>
		<li>encourage test frameworks to bottom out at assert, instead of their own ad-hoc things?</li>
		<li>what does the fn take?
		<ul>
			<li>source code forms of the assertion</li>
			<li>want access to locals</li>
		</ul>
		</li>
	</ul>
	</li>
	<li>very useful on CI
	<ul>
		<li>dump everything you know</li>
	</ul>
	</li>
</ul>

<h3>Bindable throw handler</h3>

<ul>
	<li>like the assertion handler, but tied to all (Clojure) throws</li>
	<li><code>*throw-handler*</code> should be available (in effect?) only under debug mode
	<ul>
		<li>pay for what you need</li>
	</ul>
	</li>
	<li>open questions
	<ul>
		<li>what does the fn take?
		<ul>
			<li>source code forms</li>
			<li>access to locals</li>
			<li>args to exception</li>
		</ul>
		</li>
	</ul>
	</li>
	<li>very useful in CI
	<ul>
		<li>dump everything you know</li>
	</ul>
	</li>
</ul>

<h3>Platform-based handler</h3>

Is there JVM support for automating handlers like the assert handler or throw handler? If these exist, and are flexible and easy to deploy, could use them instead of extending Clojure.

<ul>
	<li>not aware of any</li>
	<li>Clojure versions would work on other platforms</li>
</ul>

<h3>Bindable edge handler</h3>

<ul>
	<li>try to make all exceptions handle-able by wrapping clojure/java boundary everywhere</li>
	<li>when exception from Java land hits Clojure boundary, call the handler before propagating it</li>
	<li>attempt here is to respond closer to the problem
	<ul>
		<li>but halfway between the problem and the outer handler isn't much better than a full stack unwind</li>
		<li>nothing special about the Clojure/Java boundary</li>
	</ul>
	</li>
	<li>pervasive implementation and performance issues</li>
	<li>non-idiomatic wrapping</li>
	<li>ok, this is a crazy idea</li>
</ul>

<h3>Weaknesses of the modest proposal</h3>

<ul>
	<li>still no automatic way to discover relevant bindings
	<ul>
		<li>documentation, of course</li>
		<li>but no programmatic way to discover relevant situation handlers</li>
		<li>checked exceptions got this half-right</li>
	</ul>
	</li>
	<li>Java/Clojure boundary visible on exceptions-as-data
	<ul>
		<li>Clojure exception can give you everything</li>
		<li>with Java exception you have to ask by calling a fn</li>
	</ul>
	</li>
	<li>Java/Clojure boundary visible on throw handler
	<ul>
		<li>no straigtforward way to sneak into Java</li>
	</ul>
	</li>
	<li>if there is any commonality in how to write a bindable handler, it isn't captured here</li>
	<li>nothing stops an exception from being unnecessarily data-ized multiple times</li>
</ul>