On Tue, 2011-02-08 at 09:01 -0500, Stuart Halloway wrote: > This conversation began on Twitter [1] but I want to continue it on > the mailing list as it may be of broader interest. > > > The core team is very interested in improving error messages, and > relatively less interested in more code to manipulate stack traces, > for the following reasons: > > > (1) The language sits at the bottom, and must solve the problems > nobody higher up can solve. Error messages are created at the point of > an error, and if the language gets it wrong you may not have the > information to fix it later. OTOH, any old library code can reduce a > stacktrace. > > > (2) Better error messages are easy to implement [2].
This seems questionable to me. My car will post a 27B/6 error to the diagnostic interface which tells my mechanic that the oxygen sensor has failed. For my mechanic that is a good error message. However, when my car stalls it would be useless to display 27B/6. A more useful error message might be "Call a tow truck". "Good" error messages are extremely context sensitive and are relative to the mindset of the person. There are times when a null pointer exception is very precise and times when it is completely content-free. The null pointer could happen because there was missing input somewhere else in the program. So even for a specific programmer the exception might have no meaning. So my question is: What is the audience for the error message? In my experience the Symbolics machines had great error messages. They would throw you into emacs editing the failing source with the cursor pointed at the specific failing line. You could fix the failing line and continue from the point of the error. So a good error message would contain information that would allow Slime to do the same thing. That would probably be the filename and source line of the failure. This could be automated by the compiler. The compiler could see a class of symbols, such as 'error' or 'blather' or 'opine' and automatically lay down code to output (file . line) pairs. Slime could then use this information to open the file@line. > Most oddball errors are in macroexpansion, so there is no runtime cost > to doing extra work to improve error messages. These can be > implemented as pure functions, so even a relative beginner could > contribute a patch. > > > (3) The clojure.repl/pst macro in 1.3 already provides better control > of stack trace spewage at the REPL. > > > Please let us know when you get a misleading error message from a > macroexpansion, so we can make it better. Or contribute a patch along > the lines of [2]. > > > Thanks, > Stu > > > Stuart Halloway > Clojure/core > http://clojure.com > > > [1] http://twitter.com/marick/statuses/33760838540070912 > [2] > https://github.com/clojure/clojure/commit/d694d6d45fb46195ae4de01aab9a2b9f9c06355f > > -- > 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
