Hello Stuart
One of problem, that sometime arise (at least for me) - errors in code
that is performed lazily - stack trace contains data about point where
it's evaluated, not where it's created:
for example, let look to something like:
I have a function that combines several functions
(defn make-funcs [& funcs]
(fn [data]
(flatten (map #(% data) funcs))))
and function that use these data, something like:
(defn do-something [data]
((make-funcs [func1 func2]) data))
if I omit 'funcs' in map call in 'make-funcs', then I'll get following
trace when data will evaluated in do-something, but it will contain no
pointer to make-funcs:
XXXXXXX core [ERROR] - java.lang.RuntimeException:
java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.IllegalArgumentException: Wrong number of args (1) passed
to: core$map
at clojure.lang.LazySeq.sval (LazySeq.java:47)
clojure.lang.LazySeq.seq (LazySeq.java:63)
clojure.lang.RT.seq (RT.java:450)
clojure.core$seq.invoke (core.clj:122)
clojure.core$dorun.invoke (core.clj:2450)
clojure.core$doall.invoke (core.clj:2465)
my_ns$do_something.invoke (my_ns.clj:189)
Maybe it's possible to keep information about where this lazy seq was created?
On Tue, Feb 8, 2011 at 3:01 PM, Stuart Halloway
<stuart.hallo...@gmail.com> 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]. 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
--
With best wishes, Alex Ott, MBA
http://alexott.net/
Tiwtter: alexott_en (English), alexott (Russian)
Skype: alex.ott
--
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
