Another idea I had was this (and I haven't had a chance to check the source code to see if any of this is already implemented):
When Clojure creates a new Java class for a function, it should find a way to hang the meta-data for the function as a static field on the function. Alternately, there should be an API that takes a generated function class (or even function class name) and returns the meta data. A print-stack-trace function would take apart the stack trace, and for Clojure function classes, substitute something meaningful for those frames, such as the namespace qualified name and file/line number. In other words, identify the class name from the Java StackFrame element, find the meta-data for the originating function, pretty print that in place of the normal Java stack frame. On Sun, Nov 16, 2008 at 5:33 AM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > > > On Nov 14, 3:50 pm, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote: >> On Nov 14, 2008, at 3:11 PM, Howard Lewis Ship wrote: >> >> > The point is, an exception that said something like: >> >> > "Expected java.lang.Comparable but received :king" would have helped >> > me unravel this much, much easier! >> >> I agree. Clojure should give all the information it can about the >> object(s) involved in the failure. There are other places where the >> class of the object is given, but not its string representation. Any >> juicy info that's easily available should be made part of the >> exception message. > > I'm certainly interested in improving the error reporting, but in this > partiicular case: > > java.lang.ClassCastException: clojure.lang.LazyCons > > is my all-time pet-peeve exception message, and it comes from the JVM. > Why on earth they didn't report the types of both what you had and > what you were trying to cast to is completely baffling and can only be > described as a bug, which seems to be fixed in JDK 6, which reports > "XXX cannot be cast to YYY". > > For every library and every app to have to wrap every cast in a try > block simply in order to get this message to say what it ought to is > not productive, IMO. > > One issue with trying to capture string representations is that they > can be arbitrarily long. Certainly; I think you would want to have a way of converting an object to a "short" string description. Most Java objects would accomplish this with just toString(), but some kind of marker interface (perhaps) on the list, set, etc. would be necessary. .. when present, RT would supply a shorter reprsentation, or just an indication of the type. Certainly, an endless lazy sequence would be problematic! > > Rich > > > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
