+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 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 code in the callstack would be > separated by 1 line rather 10 or 20, so you could more easily trace > the execution path. > > On Feb 8, 8:11 pm, "John R. Williams" <shponglesp...@gmail.com> wrote:> 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" java.lang.ArithmeticException: Divide by > > zero (macro-fail.clj:0) > > at clojure.lang.Compiler.eval(Compiler.java:5365) > > at clojure.lang.Compiler.load(Compiler.java:5759) > > at clojure.lang.Compiler.loadFile(Compiler.java:5722) > > at clojure.main$load_script__5893.invoke(main.clj:213) > > at clojure.main$script_opt__5922.invoke(main.clj:265) > > at clojure.main$main__5940.doInvoke(main.clj:346) > > at clojure.lang.RestFn.invoke(RestFn.java:409) > > at clojure.lang.Var.invoke(Var.java:365) > > at clojure.lang.AFn.applyToHelper(AFn.java:165) > > at clojure.lang.Var.applyTo(Var.java:482) > > at clojure.main.main(main.java:37) > > Caused by: java.lang.ArithmeticException: Divide by zero > > at clojure.lang.Numbers.divide(Numbers.java:138) > > at user$broken__1.invoke(macro-fail.clj:2) > > at clojure.lang.Var.invoke(Var.java:369) > > at clojure.lang.AFn.applyToHelper(AFn.java:167) > > at clojure.lang.Var.applyTo(Var.java:482) > > at clojure.lang.Compiler.macroexpand1(Compiler.java:5212) > > at clojure.lang.Compiler.macroexpand(Compiler.java:5267) > > at clojure.lang.Compiler.eval(Compiler.java:5335) > > ... 10 more > > > As you can see, line 3, where the macro is used, appears nowhere in > > the stack trace. I've made some progress addressing this issue by > > adding an exception handler in Compiler.macroexpand1. I also > > discovered that, although the reader attaches line numbers to the > > forms it reads, it does not attach file names. I've added some code in > > LispReader.java that attaches the file name, but it does so by getting > > the value of Compiler.SOURCE_PATH. I suspect a less hackish fix would > > involve passing a filename to the reader some other way. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
