try catch blocks with boost.Test

Question

I have a (Class member) function which I wish to avoid app crash due to ambiguity. For that purpose I have added a try catch bock as shown below:

void getGene(unsigned int position){
     T val;
     try {
        val =  _genome.at(_isCircular ? position % _genome.size() : position);
     }
     catch (std::exception& e) {
         std::cerr << "Error in [" << __PRETTY_FUNCTION__ << "]: " 
                   << e.what()  << std::endl;
         exit(1);
    }
    return val;
}

Now, I wish to add a Boost unit test, which I thought of doing something like

BOOST_AUTO_TEST_CASE(nonCircularGenome_test){

   // set size to 10
   test.setSize(10);
   // set non circular
   test.setNonCircular();    

   // gene at site # 12 does not exist in a 10-site long genome, must throw an exception
   BOOST_CHECK_THROW(test.getGene(12), std::out_of_range);

The problem is, I can't get both these things work. The try-catch block works well in release setup. However, this test works, only if I remove the try-catch block and let the function throw the exception.

What is the best way to get both these things working, so that a user is prompted with correct error on the go, while tests check explicitly on debug? One way is the use #ifdef/#endif DEBUG blocks, but I wish to avoid pre-processor macros.

Thanks in advance,

Nikhil

Andy Prowl · Answer 1 · 2013-06-17T16:31:12.160

3

You seem to be misunderstanding the scope and purpose of exceptions - and perhaps of error handling in general.

First of all, you should define what are the pre-conditions of your function: does getGene() always expect position to be a valid one? Does it expect its clients to never provide invalid positions?

If that is the case, a client that provides an invalid position (even if the client is a test routine) is breaking the contract with the getGene() (in particular, it is breaking its pre-condition), and breaking a contract is undefined behavior by definition. You cannot test undefined behavior, so you should remove your test.

On the other hand, if your function has a wide contract, i.e. it allows the clients to pass in any position (even invalid ones) and (a) throws an exception or (b) returns an error code to communicate failure when the position is invalid, then the exit(1) line should not be there, because you are quitting the program and control is not transferred back to the caller.

One possibility is to re-throw the exception after logging the diagnostic:

T getGene(unsigned int position){
    T val;
    try {
       val =  _genome.at(_isCircular ? position % _genome.size() : position);
    }
    catch (std::exception& e) {
        std::cerr << "Error in [" << __PRETTY_FUNCTION__ << "]: " 
                  << e.what()  << std::endl;

        throw;
//      ^^^^^
    }
    return val;
}

And if you do not need to print a diagnostic, just let the exception naturally propagate:

T getGene(unsigned int position){
    return _genome.at(_isCircular ? position % _genome.size() : position);
}

edited Jun 17 '13 at 16:31

answered Jun 17 '13 at 16:18

Andy Prowl

124,023
23
387
451

+1, but some details... you *can* sometimes test undefined behavior, it depends on what undefined behavior. In Lakos terms, you can test *soft* undefined behavior (i.e. out of contract calls to your library) but not *hard* undefined behavior (i.e. something that has already triggered undefined behavior in a library and/or language). As a matter of fact there is a proposal ([n3604](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3604.pdf)) to add some support for this at the language level, and [BSL](https://github.com/bloomberg/bsl) has a library level implementation. – David Rodríguez - dribeas Jun 17 '13 at 17:45
@DavidRodríguez-dribeas: I must confess I read that interesting proposal too long ago to remember exactly its contents. Now I'm a bit puzzled so I will ask you if you don't mind: if breaking a pre-condition is undefined behavior, then invoking that function by breaking that pre-condition is going to trigger undefined behavior, and that means our test assertion cannot expect a consistent outcome. Am I misunderstanding this? Or is our test supposed to run in a context where what is normally undefined behavior is now a well-defined behavior (e.g throwing an exception)? – Andy Prowl Jun 17 '13 at 17:52
The point is that in your function you can test the preconditions *before* your function itself causes undefined behavior somewhere else by means of one of the assert macros. The framework at Bloomberg/BSL and the proposal enable configuration of what happens when an assertion is triggered from `main` (well, from a single point in code at any rate). Now in a test suite (you can check BSL tests) you can configure the assert handler to be a unique exception, and in that way you can add tests that verify that your code is able to *detect* UB on your own interface [...] – David Rodríguez - dribeas Jun 17 '13 at 18:00
[...] this can itself be used in client code tests to help make your code more robust. The interface still has undefined behavior as the different asserts can differ in different build modes, and the effect of triggering the assert can also be changed even at runtime (for those checks not removed at compile time). For example, you can have a function that if the library is built with some flags will throw an exception, and if it is built with other flags does not check at all and causes *hard* undefined behavior somewhere else. – David Rodríguez - dribeas Jun 17 '13 at 18:04
Summarizing: the fact that the interface is narrow and has undefined behavior when called out of contract does not mean that you cannot check the inputs *before* the function itself causes UB, or that you need to widen the contract by providing well defined behavior for all possible inputs. – David Rodríguez - dribeas Jun 17 '13 at 18:06
@AndyProwl: Thanks a lot for your comments. I do understand your point about breaking the contract. My main problem is the position in general can be any (integral) number since the vector could be a circular one. However, if the vector is not a circular one, I don't want the user to step on a position outside the limits. For this purpose, I moved from [] operator to .at() method of the vector and wished to convey the error thrown by vector::at() to the user in a meaningful manner. – Nikhil J Joshi Jun 18 '13 at 11:09
I think I will go back to my if() loops for explicit checks. Your suggestions does not work for me, as letting the error propagate as is crashes the run and the user will be confused what went wrong. Thanks, btw - Nikhil – Nikhil J Joshi Jun 18 '13 at 11:13

try catch blocks with boost.Test

1 Answers1