Changes the signature of intercept to return the Throwable.

[jupco]

Returning the exception that was intercepted allows the library users to inspect the exception a little bit more, so they don't have to rely on just the expected type and can compare, as an example, the error message.

Would you prefer to have this new signature as a new function for compat issues maybe?

[eed3si9n]

Therein lies the problem. scala-verify (and its parent Minitest) strictly checks for the Unit type, and it's not fun to put () right after you actually did the checking.

[dwijnand]

That sucks. I think it's much better to switch the API to not use exceptions and other side effects.

[eed3si9n]

Everything is a side effect in the test framework. The logs, asserting, intercepting the exception etc.

[eed3si9n]

One way to make this whole thing more purely functional would be to make assert(...) return Assertion but in reality, I find it more convenient to be able to to do

  test("something") {
    if (something) {
      assert("bla" == foo)
    }
    List(1, 2, 3) foreach { x = > assert("bla" == bar(x)) }
  }

and trying to fold them with and, or worse forget them.

[dwijnand]

The pure functional way to avoid that I think would look something like this (in Scala):

test("something")(for {
  () <- assert("bla" == foo).when(something)
  () <- List(1, 2, 3).traverse(x => assert("bla" == bar(x)))
} yield ())

which, if you prefer, you could formulate as:

test("something")(testFoo >> testBar)
def testFoo = assert("bla" == foo).when(something)
def testBar = List(1, 2, 3).traverse(x => assert("bla" == bar(x)))

and/or you could extract the inner bar assert.

[sjrd]

Yeah ... Good luck convincing me that the purely functional test is more readable or even more maintainable.

TBH purely functional testing seems actually harmful to me. I don't even begin to understand what could possibly be the benefit.

[dwijnand]

The usual reasons: easier to reason, reuse, refactor and create abstractions over.

[sjrd]

Er ... Concrete example? Because from the above, and from everything I've seen about purely functional testing, it makes things harder to reason about, reuse, refactor and create abstractions over ... Let alone getting them right in the first place by not forgetting to chain one of the asserts in the middle of a loop!

[dwijnand]

Enabling value discard warning definitely helps to avoid those issues.

[dwijnand]

Probably even better to return E here, which you can do by casting with the E value.

[eed3si9n]

As a precedence, ScalaTest's intercept does that - http://www.scalatest.org/user_guide/using_assertions#expectedExceptions

Except, ScalaTest provides assertThrows and intercept. Given that this is a sugar that the user can easily implement using try-catch anyway, I want to be cautious on trying to stay minimal.

[ekrich]

I agree with returning the exception for inspection. When working on java stdlib in Scala Native e.g. it is helpful to inspect the error message to make sure it matches the JVM error message. Although, not part of the API, in practice having the same message is helpful to not create surprises.