On Sep 17, 2:55 pm, Allen Rohner <[EMAIL PROTECTED]> wrote:
> > 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.
>
> I don't think that unwillingness is the only criteria here. One reason
> is for consistency. We're already heading down the track of making
> compiler error messages easier to read. It doesn't seem very friendly
> to make the compiler error messages easier and then intentionally
> leave the runtime errors obfuscated.
Ok, let's tone down the rhetoric please. The runtime errors are not
obfuscated. In the specific case you gave, an arity error, a _runtime_
error will always look like this:
java.lang.IllegalArgumentException: Wrong number of args passed to:
foo
at clojure.lang.AFn.throwArity(AFn.java:460)
at clojure.lang.AFn.invoke(AFn.java:71)
at somens.somefn__2291.invoke(your-file.clj:6)
...
It reports the function being called, and 3 lines down, the point of
call. The point of call is not first because fns are implemented on
top of abstract classes, and the abstract class uses a helper to
report the error. The solutions you are proposing for compile-time
errors cannot work here, as sourcepath and line are not bound to
anything useful at runtime.
>
> > 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.
>
> I've seen cases where the default Java exception.printStackTrace()
> doesn't include the entire stack and the part that I care about is
> hidden in that "and 60 more lines" message.
Again, more rhetoric. Let's focus on concrete cases. Currently the
repl recursively seeks the cause and puts it first.
> My goal in creating a new exception type was to avoid copy&paste code.
> At the point where you want to throw a new exception, I see a few
> possible choices here.
>
> 1) throw new java.lang.IllegalArgumentException("Too many arguments to
> def");
> 2) throw new
> java.lang.IllegalArgumentException(Compiler.SOURCE_PATH.get() + " line
> " + Compiler.LINE_AFTER.get() + "Too many arguments to def");
> 3) throw new
> java.lang.IllegalArgumentException(Compiler.exceptionPrefix() + "Too
> many arguments to def");
> 4) throw new Clojure.CompileError("too many arguments to def");
>
> where Compiler.exceptionPrefix() is
>
> String exceptionPrefix()
> {
> return Compiler.SOURCE_PATH.get() + " line " +
> Compiler.LINE_AFTER.get();
>
> }
>
> 1 is the current code. 2,3,4 have the same behavior, with increasing
> levels of encapsulation. I assume you are in favor of 3) then?
>
Compiler.analyzeSeq already wraps the cause with an exception
containing the file and line. I'll need to see examples of where
that's not working.
Let's talk about concrete examples of the problem before we go on
further about the solution. And no more rhetoric please.
Thanks,
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
-~----------~----~----~----~------~----~------~--~---
