I'm concerned specifically about exceptions that occur during macro
expansion. As often as not, these exceptions are the result of calling the
macro with incorrect arguments rather than any problem in the macro itself,
but the stack trace doesn't contain enough information to locate the
offending
In the example, you can find a reference to the actual macro (line and name)
in the second part (Caused by:). By the nature of macro's I think this might
be not the most human way to get the line number, but surely the way the JVM
sees it.
2010/2/11 John Williams shponglesp...@gmail.com
I'm
+1 on this. Although of course you could just use the shell for this
(e.g. grep or awk). But it's certainly nicer to have that integrated
in the compiler (possibly also in the compiled code?)
On Feb 9, 12:45 pm, Jeff Rose ros...@gmail.com wrote:
I agree, the error reporting from the compiler can
I agree, the error reporting from the compiler can often be hard to
dig through. Besides showing both the location of the macro
definition and its usage, it would be nice to hide all of the
clojure.lang.* calls in the stack trace by default, or fold them into
a single line. That way the user
The Clojure compiler is not very helpful when it comes to debugging
exceptions that occur while macros are being expanded. As an example,
consider this code:
;; macro-fail.clj
(defmacro broken [] (/ 0 0))
(broken)
Here's the stack trace I get when I compile this file:
Exception in thread main
On 8 February 2010 20:11, John R. Williams shponglesp...@gmail.com wrote:
;; macro-fail.clj
(defmacro broken [] (/ 0 0))
(broken)
[ ... ]
As you can see, line 3, where the macro is used, appears nowhere in
the stack trace.
That's because execution never reaches this point, because the (/ 0
