Don't catch all exceptions in read-file-ns-decl


I spent a while trying to work out where a bug was coming from after upgrading tools.namespace. Eventually I tracked it down to an exception being thrown in parse/read-ns-decl when it calls reader/read. This was an error in tools.namespace code, not the parsing code. The error was an ArityException that was occurring because the wrong version of tools.reader was on the Classpath.

Is it desirable to catch all exceptions here, or would it be better to only catch exceptions thrown by the parsing (which seems to be the intent)? I'm not sure if it's possible to distinguish these though...





Stuart Sierra
January 5, 2016, 8:32 PM

fix included in 0.3.0-alpha3 release

Stuart Sierra
January 5, 2016, 2:05 PM

It appears that tools.reader wraps all exceptions in ex-info with :type :reader-exception

Stuart Sierra
November 24, 2015, 2:02 PM

I've never been entirely happy with the behavior of ignoring exceptions. But the alternative has been to break on any syntax error in any file. Since it's fairly common to have syntax errors during development, the trade-off was to allow tools.namespace to continue working.

In 0.3.0 I moved the try/catch one level higher from c.t.n.parse/read-ns-decl to c.t.n.file/read-file-ns-decl, specifically to detect this case.

With the tools.reader replacing clojure.core/read in tools.namespace 0.3.0, it may be possible to distinguish parsing errors from other kinds of errors.

Your pinned fields
Click on the next to a field label to start pinning.


Stuart Sierra


Daniel Compton