I do not know if Leiningen is involved in the difference in the reproduction project linked below yet (I am testing with the latest Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg? ...` expression that gives no error when running 'lein test' with Clojure 1.9.0, but does with Clojure 1.10.0. I do not know if it is the same root cause as Mark's example or not, but wanted to create this in hopes it represents a minimal test case to reproduce the behavior difference.
https://github.com/jafingerhut/clojure-110-is-thrown Andy On Tue, Dec 18, 2018 at 7:07 AM Alex Miller <a...@puredanger.com> wrote: > In particular, I am challenging this assertion from the original post: > > However, the following test (using is from clojure.test) used to work > prior to 1.10, but now fails: > > => (is (thrown? AssertionError (f true))) > Unexpected error (AssertionError) macroexpanding f at > (test:localhost:62048(clj)*:268:56). > Assert failed: (number? x) > > > When I do this on 1.9 I see: > > user=> (is (thrown? AssertionError (f true))) > CompilerException java.lang.AssertionError: Assert failed: (number? x), > compiling:(NO_SOURCE_PATH:20:29) > > > Which is printed differently but is the same behavior, because this is > happening while expanding the is, not during execution. > > I believe you're seeing a change in your test suite, I'm just having a > hard time reproducing what you're seeing. > > > On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote: >> >> This particular example given fails in a similar way on 1.9. Could you >> give me something closer to what you are actually seeing in your test >> suite? Specifically something that is a passing clojure.test test on 1.9 >> but a failure/error on 1.10? >> >> The problem with the given example is that it fails during macroexpansion >> of the test itself, not during test execution, and I don't think that's the >> case you're trying to replicate. >> >> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote: >>> >>> I think the relevant change here is that exceptions thrown during >>> macroexpansion are now wrapped into CompilerExceptions as a way to attach >>> all of the source context information. The REPL understands this and still >>> prints the original cause so the printing hides some of that structure (but >>> you can see it by looking at the exception chain). >>> >>> This here is a particularly tricky case here though and I think there >>> might be something else coming into play, still looking at it. There was a >>> couple other changes inside the compiler exception handling that might also >>> be coming into play. >>> >>> (Would have been great to see this during a pre-release build rather >>> than after release! ;) >>> >>> >>> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote: >>>> >>>> Agreed. It is not a problem for functions which throw AssertionErrors, >>>> only macros. But this is a change in behavior which breaks test suites >>>> which passed previously. >>>> >>>> On Tue, Dec 18, 2018 at 1:48 AM alex <fmno...@gmail.com> wrote: >>>> >>>>> I'm not sure, but probably it behaves so because of throwing at >>>>> macroexpand stage. >>>>> >>>>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler >>>>> написал: >>>>>> >>>>>> Consider the following macro: >>>>>> >>>>>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5)) >>>>>> => (f 3) >>>>>> 8 >>>>>> => (f true) >>>>>> Unexpected error (AssertionError) macroexpanding f at >>>>>> (test:localhost:62048(clj)*:265:28). >>>>>> Assert failed: (number? x) >>>>>> >>>>>> So, as expected it throws an AssertionError if passed a non-number. >>>>>> However, the following test (using is from clojure.test) used to work >>>>>> prior to 1.10, but now fails: >>>>>> >>>>>> => (is (thrown? AssertionError (f true))) >>>>>> Unexpected error (AssertionError) macroexpanding f at >>>>>> (test:localhost:62048(clj)*:268:56). >>>>>> Assert failed: (number? x) >>>>>> >>>>>> What's odd is that the macro still throws an AssertionError, but the >>>>>> `thrown?` inside the `is` is no longer intercepting the AssertionError, >>>>>> so >>>>>> the test doesn't pass -- instead the error causes a failure in the test >>>>>> suite. >>>>>> >>>>> -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
