Re: error reporting for macro expansion
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 > 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 macro call. For instance, the stack trace I posted reports > macro-fail.clj line 0 as the ultimate source of the problem, even though the > macro is called on line 3. > > I've done some more tests using the 1.0 release as well as the latest head > from git, and in both versions, the stack trace contains the name of the > file where the macro is called, but the line number is always 0. Since the > file name is correct, I think my comments about hacking the reader were > off-base, but there is definitely a problem with reporting the correct line > number. > > On Mon, Feb 8, 2010 at 2:08 PM, Michał Marczyk > wrote: > >> On 8 February 2010 20:11, John R. Williams >> 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 0) >> bit gets executed at macro expansion time. You'd have to syntax-quote >> it to fail at runtime: >> >> (defmacro broken [] `(/ 0 0)) >> >> (A regular quote would probably also do.) >> >> Also, note the user$broken ... line in your stack trace -- it does >> contain a useful indication of the source of the problem. >> >> Sincerely, >> Michał >> >> -- >> 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 >> > > -- > 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 > -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... - http://esperanto.net - http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- 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
Re: error reporting for macro expansion
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 macro call. For instance, the stack trace I posted reports macro-fail.clj line 0 as the ultimate source of the problem, even though the macro is called on line 3. I've done some more tests using the 1.0 release as well as the latest head from git, and in both versions, the stack trace contains the name of the file where the macro is called, but the line number is always 0. Since the file name is correct, I think my comments about hacking the reader were off-base, but there is definitely a problem with reporting the correct line number. On Mon, Feb 8, 2010 at 2:08 PM, Michał Marczyk wrote: > On 8 February 2010 20:11, John R. Williams > 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 0) > bit gets executed at macro expansion time. You'd have to syntax-quote > it to fail at runtime: > > (defmacro broken [] `(/ 0 0)) > > (A regular quote would probably also do.) > > Also, note the user$broken ... line in your stack trace -- it does > contain a useful indication of the source of the problem. > > Sincerely, > Michał > > -- > 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 > -- 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
Re: error reporting for macro expansion
+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 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" 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
Re: error reporting for macro expansion
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" 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
Re: error reporting for macro expansion
On 8 February 2010 20:11, John R. Williams 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 0) bit gets executed at macro expansion time. You'd have to syntax-quote it to fail at runtime: (defmacro broken [] `(/ 0 0)) (A regular quote would probably also do.) Also, note the user$broken ... line in your stack trace -- it does contain a useful indication of the source of the problem. Sincerely, Michał -- 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
error reporting for macro expansion
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
