On Sep 17, 1:54 pm, Allen Rohner <[EMAIL PROTECTED]> wrote:
> After feedback on my previous compiler error message patch,
> I've started looking into the problem more. My goal is to have the
> file and line number printed on every user-visible stack trace.
>
> An example of my desired output is:
>
> java.lang.IllegalArgumentException: /Users/arohner/Programming/clojure/
> broken-arity.clj Line 6: Wrong number of args passed to foo
>         at clojure.lang.AFn.throwArity(AFn.java:461)
>         at clojure.lang.AFn.invoke(AFn.java:68)
>         at user.eval__2291.invoke(broken-arity.clj:6)
>         at clojure.lang.Compiler.eval(Compiler.java:3891)
>         at clojure.lang.Compiler.load(Compiler.java:4192)
>         at clojure.lang.Compiler.loadFile(Compiler.java:4159)
>         at clojure.lang.Repl.main(Repl.java:48)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
> 25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at jline.ConsoleRunner.main(ConsoleRunner.java:69)
>
> Right now, there are 308 places where new exceptions are thrown in the
> clojure source. Rather than modify the message of each exception, I am
> thinking that it would be a good idea to make a hierarchy of clojure
> exceptions, like Clojure.SyntaxError, Clojure.RuntimeError,
> etc. The Clojure exception's getMessage() would be extended to contain
> Compiler.SOURCE_PATH and Compiler.LINE_AFTER.
>
> Then, replace all of the exceptions in the source that use 'standard'
> java exceptions like java.lang.ArrayIndexOutOfBounds and
> java.lang.IllegalArgument with one of the exceptions from the Clojure
> hierarchy.
>
> Thoughts?
>

It seems to me you need to distinguish runtime errors from compilation
errors. For runtime errors, the file and line numbers are already in
the stack trace, as Clojure emits that information in the bytecode.
For example, in the above trace:

>         at user.eval__2291.invoke(broken-arity.clj:6)

I'm not going to make any changes for people unwilling to look a few
lines down in a stack trace.

A new exception class hierarchy that duplicates these values seems
redundant. The world does not need more exception types, or a
reinvention of stack traces, IMO.

There are cases where macros mess up the line numbers, and I'll look
into reports of that.

It seems most people are having problems either:

  With a runtime error in code entered in the repl (or sent from an
editor buffer), rather than loaded, where there are no relevant source
line numbers to use.

  With a compile-time error where the source code is unacceptable to
the compiler or a macro.

It is this latter case where I see the most room for improvement,
because the stack there is the stack of the compiler execution, not
user code.

> p.s. last night I was writing Clojure code that exercises the
> different kinds of Compiler errors that can be thrown. It wouldn't
> take too much effor to turn those into a test suite. Rich, is this
> something you would be interested in having?
>

Sure. That is absolutely first priority in this case. I'm not going to
fix or accept a fix for any problem I haven't seen isolated, and agree
is, in fact, a problem.

> p.p.s My CA is in the mail

Great!

Rich

--~--~---------~--~----~------------~-------~--~----~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to