Re: [googletest] Making the assertions throw on platforms where exceptions are enabled

[Zhanyong Wan (λx.x x)]

It's already implemented (--gtest_throw_on_failure):

https://code.google.com/p/googletest/wiki/AdvancedGuide#Letting_Another_Testing_Framework_Drive

The FAQ is out-dated.  Sorry about that.  I'll fix it soon.

On Wed, Jul 3, 2013 at 3:19 PM, Piotr Jaroszyński <p.jaro...@gmail.com> wrote:

I found the following snippet in the FAQ:

• The Google Test team is considering making the assertion macros throw on platforms where exceptions are enabled (e.g. Windows, Mac OS, and Linux client-side), which will eliminate the need for the user to propagate failures from a subroutine to its caller. Therefore, you shouldn't use Google Test assertions in a destructor if your code could run on such a platform.

How hard would it be to add a flag that switches the assert mode to throwing exceptions?

--
 
---
You received this message because you are subscribed to the Google Groups "Google C++ Testing Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googletestframe...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Zhanyong

[Piotr Jaroszyński]

I wanted to make gtest use exceptions for ASSERT* even if gtest is driving. I.e. make gtest throw and *catch* the exception, mark the failure etc.

To unsubscribe from this group and stop receiving emails from it, send an email to googletestframework+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Zhanyong

[Zhanyong Wan (λx.x x)]

On Mon, Jul 8, 2013 at 12:09 PM, Piotr Jaroszyński <p.jaro...@gmail.com> wrote:

I wanted to make gtest use exceptions for ASSERT* even if gtest is driving. I.e. make gtest throw and *catch* the exception, mark the failure etc.

I'm guessing that you want this because you don't like the restriction that ASSERT* must be used in a void-returning function.  In that case, what you want isn't possible as a command-line flag, since the decision must be made at compile time (in this "assertion throws" mode, ASSERT* in a non-void function should compile; yet in the "assertion returns" mode, there's no way for such code to compile as it needs to return _some value_ from the current function but the assertion doesn't know what to return).

 

On Sunday, July 7, 2013 3:40:39 PM UTC-7, Zhanyong Wan wrote:

It's already implemented (--gtest_throw_on_failure):

https://code.google.com/p/googletest/wiki/AdvancedGuide#Letting_Another_Testing_Framework_Drive

The FAQ is out-dated.  Sorry about that.  I'll fix it soon.

On Wed, Jul 3, 2013 at 3:19 PM, Piotr Jaroszyński <p.jaro...@gmail.com> wrote:

I found the following snippet in the FAQ:

• The Google Test team is considering making the assertion macros throw on platforms where exceptions are enabled (e.g. Windows, Mac OS, and Linux client-side), which will eliminate the need for the user to propagate failures from a subroutine to its caller. Therefore, you shouldn't use Google Test assertions in a destructor if your code could run on such a platform.

How hard would it be to add a flag that switches the assert mode to throwing exceptions?

--
 
---
You received this message because you are subscribed to the Google Groups "Google C++ Testing Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googletestframework+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Zhanyong

--
 
---
You received this message because you are subscribed to the Google Groups "Google C++ Testing Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googletestframe...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
 
 
 

--
Zhanyong

[Piotr Jaroszyński]

Yes, you are right. I would be fine with a compile time flag. Any idea how much work would that be or some tips where to start if I wanted to implement that?

[Zhanyong Wan (λx.x x)]

It's rather complex.  To do what you want, gtest needs to do different things in these cases:

1. exceptions are disabled.

2a. exceptions are enabled; "assertion returns" mode; --gtest_throw_on_failure is not specified.

2b. exceptions are enabled; "assertion returns" mode; --gtest_throw_on_failure is specified.

3. exceptions are enabled; "assertion throws" mode.

#3 requires a new #if path and adds significant complexity (#1 + #2a + #2b is already complex enough).

--
Zhanyong