GMock doesn't support noexcept functions

[dotnetjunky]

Hi,

What is the current plan for supporting mocking noexcept functions? From searching StackOverflow, I understand that it's currently not possible to mock noexcept functions. Is there a workaround?

Thanks

[kuzkry]

Hi! Does this address your issue?

[dotnetjunky]

Is the MOCK_METHOD macro new in version 1.8? Our team is using 1.7 and I don't see the MOCK_METHOD macro. I only see the MOCK_METHODn macros. I'll try to update to 1.8 and give it a try.

[kuzkry]

The latest release is 1.8.1 and MOCK_METHOD was introduced after that had been published.

[thejcannon]

From skimming the MOCK_METHOD macros, it looks like noexcept expressions aren't supported.
Stuff like noexcept(false) or noexcept(noexcept(A+B))

[kuzkry]

@thejcannon, you aren't right, code with noexcept expressions compiles. Example:

struct Interface {
  virtual ~Interface() = default;

  virtual int foo1() const = 0;
  virtual int foo2() const = 0;
};

struct Mock : Interface {
  MOCK_METHOD(int, foo1, (), (const, override, noexcept(false)));
  MOCK_METHOD(int, foo2, (), (const, override, noexcept(noexcept(1 + 2))));
};

[thejcannon]

Oh man, it's worse than expected. It compiles, but has the wrong side-effects.

struct Interface {
  virtual ~Interface() = default;
  virtual int foo1() const noexcept(false) = 0;
};

struct Mock : Interface {
  MOCK_METHOD(int, foo1, (), (const, override, noexcept(false)));
};

static_assert(
    !noexcept(std::declval<Mock>().foo1())
);
static_assert(
    !std::is_nothrow_invocable_v<std::remove_pointer_t<decltype(&Mock::foo1)>, Mock const*>
);

Both static assertions fail, which means foo1 is noexcept(true).

[thejcannon]

If you do Scott Meyer's little "type-displayer" trick, you'll see the mock is being declared as noexcept (no condition). foo1 has type:
int (Mock::*)() const noexcept

Probably an issue with how the macro handles noexcept. You can see here that it either slaps noexcept on the generated mock or it doesn't. The preprocessor logic here essentially boils down to "if any of the spec arguments start with a noexcept". So noexcept, noexcept(true), noexcept(false), noexcept(noxcept(A+B)) will all evaluate to some truthy value, and line 109 will slap noexcept on those methods.

This comment seems to imply the authors know about this.

[kuzkry]

Oh my goodness! There's nothing like a lovely hidden bug, isn't it? ;)