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.
