That way we could use our existing constraints on it.

Assert::That(ExceptionThrownBy(a, &A::foo).what(), Contains("ouch!"));

/J

   Assert::That(ExceptionThrownBy<std::exception>(a, &A::foo).what(),
Contains("ouch!"));

Maybe Thrown() is a simpler name for such a helper function, á la

   Assert::That(Thrown<std::exception>(a, &A::foo).what(), Contains("ouch!"));

There's also the complication of what happens if the method doesn't
throw or if it throws an unrelated exception. Not sure about that.

Interesting take!

- Kim

template<...>
ExceptionType Thrown(InstanceType i, MethodType m)
{
  try
  {
    (i.*m)();
  }
  catch(const ExceptionType& e)
  {
    return e;
  }
  catch(...)
  {
     Assert::Failure("wrong exception");
  }

  Assert::Failure("no exception"!);

I got the following working. Is it readable? Useful?

class ClassWithExceptions
{
public:
  int Method()
  {
    throw std::logic_error("ouch!");
  }

  Spec(CanDetectExceptions)
  {
    Assert::That(Thrown<std::logic_error>(objectUnderTest,
&ClassWithExceptions::Method).what(), Is().EqualTo("ouch!"));
  }

I can' t really think of a valid syntax at the moment, but to me it
feels important to keep the imperative call syntax;

  CPPUNIT_ASSERT_THROWS(objectUnderTest.Method(1, 2, 3), std::logic_error);

rather than the awkward method pointer + args.

This speaks in favor of a preprocessor-based solution, that can
capture a full expression for delayed execution inside an exception
handler, but I can't find a nice way to make that interact with
Assert::That.

- Kim

We could have a macro like this:

Throws(std::exception, objectUnderTest.Method(1, 2, 3))

that fails if an exception of the correct type is not thrown.

We could have that macro return the exception if the test succeeds,
and make assertions later:

std::exception e = Throws(std::exception, objectUnderTest.Method(1, 2, 3));
Assert::That(e.what(), Contains("error!"));

/J

I'll try and build something along these lines as well, and see if I
can overcome my preconceptions.

- Kim

While brainstorming, I got the following to work at least:

  Spec(CanAssertOnLastException)
  {
    AssertThrows(std::logic_error, objectUnderTest.LogicError());
    Assert::That(LastException<std::logic_error>().what(),
Contains("not logical!"));
  }

If the AssertThrows macro succeeds, it stores the exception in a
static auto_ptr.

I think it's quite readable, but there is a risk of cross-test
contamination because of the static storage. And the implementation
with an auto_ptr isn't as pretty as I would have wanted.

/J

Perhaps if we macrofy the following?

That would make it possible to have the syntax

auto_ptr<exception> last_exception  = Throws(exception,
objectUnderTest.foo(5));

It demands a proper copy constructor on the exception and the
igloo_last_exception variable would stop us from using it twice in a method.

/J

std::auto_ptr<std::logic_error> igloo_last_exception;
{
  bool igloo_wrong_exception = false;
  try
  {
  objectUnderTest.foo(5);
    std::cout << "No exception!" << std::endl;
  }
  catch(const std::logic_error& e)
  {
    igloo_last_exception = std::auto_ptr<std::logic_error>(new
std::logic_error(e));
  }
  catch(...)
  {
  igloo_wrong_exception = true;
  }
  std::cout << "wrong: " << igloo_wrong_exception << std::endl;

But I wonder if we could keep a stack of caught exceptions? Or
multiple stacks, one per type, or something?

- Kim

http://www.squidoo.com/cplusplus-behaviour-driven-development-tools#m...

They do not match up with the templated ones that you guys will come
up with, but they have been good enough to set me off.

Danny

On Oct 14, 7:54 pm, Joakim Karlsson <joa...@jkarlsson.com> wrote:

Your ShouldThrowWhatError macro is what started me on trying to come
up with a solution for asserting on any characteristic of a thrown
exception.

/J

Jonas Blunck suggested using __thread for storage, and call each test
on its own thread. MIght be worth a try. We'll have to check if there
are any restrictions on what platforms and compilers support TLS.

[1] http://github.com/joakimkarlsson/igloo/blob/master/tests/exceptions_t...

Something like;

  template< class ExceptionType >
  struct LastExceptionResetter {
    ~LastExceptionResetter() {
         ExceptionStorage<ExceptionType>::last_exception = NULL;
     }
  };

... and then instantiate LastExceptionResetter<EXCEPTION_TYPE>
somewhere in the scope of AssertThrows.

If running tests in parallel is something we want to allow then
last_exception needs to be thread-local, of course, though I'm not
sure the rest of the framework is going to play nicely.

Now that we're degenerating into macros, maybe we should reconsider my
previous (nasty!) attempt that allowed Assert::Throws(...)?

- Kim

It looks like the library (or its techniques) might be useful to us,
though I haven't read it thoroughly yet.

- Kim

Since we will need macros to add __FILE__ and __LINE_ to get nicer
output we should perhaps go with macros a' la AssertThat or similar.

/J

Please take a look and see if it looks good.

Tests:
http://github.com/joakimkarlsson/igloo/blob/master/tests/exceptions_t...

Code:
http://github.com/joakimkarlsson/igloo/blob/master/igloo/core/excepti...

/J

The only nit I can think of is it would be safer to decorate the name
the exception storage variable even more; I've tried to add an IGLOO_
prefix to all names that are magically injected into the user's
namespace. E.g.:

 ExceptionStorage<EXCEPTION_TYPE>
IGLOO_CONCAT(IGLOO_exception_storage_, __LINE__);
IGLOO_CONCAT(IGLOO_exception_storage_,
__LINE__).compiler_thinks_i_am_unused(); \

The nastier the name is, the less risk of collisions :-)

- Kim

/J