gmock and exception specifications

[Gottschalk, Jason]

Hi,

 

I am a newbie to gmock so please be patient.  My organization is prototyping the use of gmock as our mocking framework.

 

Googlemock does not appear to support the use of exception specifications.  Here is a simple example:

 

class Shape {

public:

    virtual ~Shape() {}

    virtual void draw() throw(ShapeException) = 0;

};

 

…

 

class MockShape : public Shape {

public:

    MOCK_METHOD0(draw, void() throw(ShapeException));

};

 

If I remove the exception specification (from the interface and the mock), then I can successfully create a mock object for the interface.  The “problem” is that the exception specification is part of the signature of the method.

 

Googlemock ignores the exception specification, and the compiler detects that my derived class (i.e. the mock) has a less-restrictive exception specification than that defined by the superclass.  This is a fatal error.

 

Are there any plans to support exception specifications?  I know that exception specifications are optional, but removing them is not an acceptable alternative (to me) because I want the code that defines the interface to self-document the exceptions that the clients are required to handle.

 

--Jason

[Zhanyong Wan (λx.x x)]

Hi Jason,

You are right that Google Mock doesn't support exception
specifications. The reason is that we think exception specification
is mostly a misfeature and should be avoided in practice, even if you
use exceptions extensively. And we are not alone in this view:

- Herb Sutter (author of "Exceptional C++" and "More Exceptional
C++"): A Pragmatic Look at Exception Specifications
http://www.gotw.ca/publications/mill22.htm

- Anders Hejlsberg (chief designer of C#): The Trouble with Checked
Exceptions http://www.artima.com/intv/handcuffs.html

Therefore, while technically it's easy to introduce some new macros to
define mock methods that have exception specifications, we chose to
avoid it. I would suggest you to remove exception specs from your
design - you'll be glad you did it. :)

--
Zhanyong

[Gottschalk, Jason]

Zhanyong,

Thank you for your response. I will definitely take your recommendation seriously. If we remove our exception specifications, what is the best practice regarding communicating to the clients the exceptions that an interface can typically throw: comments in the code?

Also, why does Java require the use of the throws clause if this is a general programming anti-pattern; or is this simply a "misfeature" with respect to C++?

Regards,

Jason

Hi Jason,

> ...

[Zhanyong Wan (λx.x x)]

2009/4/27 Gottschalk, Jason <Jason.Go...@xerox.com>:

>
> Zhanyong,
>
> Thank you for your response.  I will definitely take your recommendation seriously.  If we remove our exception specifications, what is the best practice regarding communicating to the clients the exceptions that an interface can typically throw: comments in the code?

Comments would work.

> Also, why does Java require the use of the throws clause if this is a general programming anti-pattern; or is this simply a "misfeature" with respect to C++?

Java, like any non-trivial programming language, has misfeatures. I
cannot speak for the designers of Java, but I suspect that checked
exceptions looked like a good idea to them back then. Sometimes you
fully understand the pros and cons of a feature only after you have
had extensive experience with it.

Since C# was built after Java, it had the benefit of hindsight and was
able to avoid some mistakes in Java.

--
Zhanyong