| Home | Libraries | People | FAQ | More

### Changing the Policy Defaults

The default policies used by the library are changed by the usual configuration macro method.

For example, passing `-DBOOST_MATH_DOMAIN_ERROR_POLICY=errno_on_error` to your compiler will cause domain errors to set `::errno` and return a NaN rather than the usual default behaviour of throwing a `std::domain_error` exception.

| Tip
For Microsoft Visual Studio,you can add to the Project Property Page, C/C++, Preprocessor, Preprocessor definitions like:
    BOOST_MATH_ASSERT_UNDEFINED_POLICY=0
    BOOST_MATH_OVERFLOW_ERROR_POLICY=errno_on_error
This may be helpful to avoid complications with pre-compiled headers that may mean that the equivalent definitions in source code:
    #define BOOST_MATH_ASSERT_UNDEFINED_POLICY false
    #define BOOST_MATH_OVERFLOW_ERROR_POLICY errno_on_error
may be ignored. The compiler command line shows:
    /D "BOOST_MATH_ASSERT_UNDEFINED_POLICY=0"
    /D "BOOST_MATH_OVERFLOW_ERROR_POLICY=errno_on_error"

There is however a very important caveat to this:

| Important
Default policies changed by setting configuration macros must be changed uniformly in every translation unit in the program. Failure to follow this rule may result in violations of the "One Definition Rule (ODR)" and result in unpredictable program behaviour.

That means there are only two safe ways to use these macros:

- Edit them in boost/math/tools/user.hpp, so that the defaults are set on an installation-wide basis. Unfortunately this may not be convenient if you are using a pre-installed Boost distribution (on Linux for example).
- Set the defines in your project's Makefile or build environment, so that they are set uniformly across all translation units.

What you should not do is:

- Set the defines in the source file using `#define` as doing so almost certainly will break your program, unless you're absolutely certain that the program is restricted to a single translation unit.

And, yes, you will find examples in our test programs where we break this rule: but only because we know there will always be a single translation unit only: don't say that you weren't warned!

[error_handling_example]