David Nolen <[email protected]> writes:
Hi David,
> Do you see the same issue when working with lazy sequences? We
> definitely don't eat exceptions.
No, exceptions in lazy sequences show up fine.
(defn blow-up [i]
(map #(/ 1 %) (iterate inc i)))
(take 200 (blow-up -100))
;Divide by zero
; [Thrown class java.lang.ArithmeticException]
; ...Backtrace...
; Evaluation aborted.
If I wrap that call with a (run* [q] ...), then I get a different
exception (with no backtrace), because a lazy seq is used in a place
where an IFn is expected.
Hm, I do get some backtraces inside `run', for example for such an
obvious top-level error.
(run 10 [q] (/ 1 0))
0: Numbers.java:156 clojure.lang.Numbers.divide
1: Numbers.java:3677 clojure.lang.Numbers.divide
2: NO_SOURCE_FILE:1 de.uni-koblenz.ist.funtg.funrl/eval6264[fn]
3: logic.clj:885 clojure.core.logic/eval2958[fn]
4: LazySeq.java:42 clojure.lang.LazySeq.sval
5: LazySeq.java:67 clojure.lang.LazySeq.seq
6: RT.java:466 clojure.lang.RT.seq
7: core.clj:133 clojure.core/seq
8: core.clj:2499 clojure.core/take[fn]
9: LazySeq.java:42 clojure.lang.LazySeq.sval
If I hide the division by zero inside some relation, though, then the
exception doesn't put me in the debugger.
(defn wrongo [a b]
(fn [s]
(unify s [a b] [1 (/ 1 0)])))
(run 10 [q] (wrongo q 0))
; Evaluation aborted.
(pst *e)
ArithmeticException Divide by zero
clojure.lang.Numbers.divide (Numbers.java:156)
clojure.lang.Numbers.divide (Numbers.java:3677)
de.uni-koblenz.ist.funtg.funrl/wrongo/fn--6233 (NO_SOURCE_FILE:1)
clojure.core.logic.Substitutions (logic.clj:207)
de.uni-koblenz.ist.funtg.funrl/eval6282/fn--6283/fn--6284/-inc--6285
(NO_SOURCE_FILE:1)
clojure.core.logic/eval2958/fn--2959/fn--2960 (logic.clj:885)
clojure.lang.LazySeq.sval (LazySeq.java:42)
clojure.lang.LazySeq.seq (LazySeq.java:67)
clojure.lang.RT.seq (RT.java:466)
clojure.core/seq (core.clj:133)
clojure.core/take/fn--3836 (core.clj:2499)
clojure.lang.LazySeq.sval (LazySeq.java:42)
nil
Comparing the backtraces, the obvious difference is the generated names.
I wasn't even aware that a function's qualified name may contain more
than one slash. Maybe the problem is that clj-stacktrace stumbles upon
those names?
But on the other hand: since *e contains the last exception and that is
the divide by zero exception and not some exception from clj-stacktrace,
this doesn't seem very likely...
But I'm still interested where those names come from. I mean, the names
of anonymous functions defined in other functions is usually something
like user/wrongo$fn3923, right?
Bye,
Tassilo
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
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
