Boost C++ Libraries of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is the documentation for a snapshot of the develop branch, built from commit 94baf1dc6d.
Library Documentation Index

Safe Numerics


exception_policy<AE, IDB, UB, UV>

Template Parameters
Model of
Inherited Valid Expressions
Function Objects
Policies Provided by the library


Create a valid exception policy from 4 function objects. This specifies the actions to be taken for different types of invalid results.


Symbol Description
e instance of a the type safe_numerics_error
message pointer to const char * error message

Template Parameters

Parameter Type Requirements Invoked when:
AE Function object callable with the expression AE()(e, message)

The operation cannot produce valid arithmetic result such as overflows, divide by zero, etc.

UB Function object callable with the expression UB()(e, message)

The result is undefined by the C++ standard

IDB Function object callable with the expression IDB()(e,

The result depends upon implementation defined behavior according to the C++ standard

UV Function object callable with the expression UV()(e, message)

A variable is not initialized

Model of


Inherited Valid Expressions

This class implements all the valid operations from the type requirements ExceptionPolicy. Aside from these, there are no other operations implemented.

Function Objects

In order to create an exception policy, one needs some function objects. The library includes some appropriate examples of these:

Name Description
ignore_exception Ignore any runtime exception and just return - thus propagating the error. This is what would happen with unsafe data types
throw_exception throw an exception of type std::system_error
trap_exception Invoke a function which is undefined. Compilers will include this function if and only if there is a possibility of a runtime error. Conversely, This will create a compile time error if there is any possibility that the operation will fail at runtime. Use the action to guarantee that your application will never produce an invalid result. Any operation invoke

But of course one is free to provide his own. Here is an example of a function object which would could be used exception conditions.

// log an exception condition but continue processing as though nothing has happened
// this would emulate the behavior of an unsafe type.
struct log_runtime_exception {
    log_runtime_exception() = default;
    void operator () (
        const boost::safe_numerics::safe_numerics_error & e,
        const char * message
            << "Caught system_error with code "
            << boost::safe_numerics::literal_string(e)
            << " and message " << message << '\n';

Policies Provided by the library

The above function object can be composed into an exception policy by this class. The library provides common policies all ready to use. In the table below, the word "loose" is used to indicate that implementation defined and undefined behavior is not considered an exceptional condition, while "strict" means the opposite. The word "exception" means that a runtime exception will be thrown. The word "trap" means that the mere possibility of an error condition will result in a compile time error.

Name Description
loose_exception_policy Throws runtime exception on any arithmetic error. Undefined and implementation defined behavior is permitted as long as it does not produce an arithmetic error.
loose_trap_policy Invoke a compile time error in any case where it's possible to result in an arithmetic error.
strict_exception_policy Throws runtime exception on any arithmetic error. Any undefined or implementation defined behavior also results in throwing an exception.
strict_trap_policy Invoke a compile time error in any case where it's possible to result in an arithmetic error, undefined behavior or implementation defined behavior
default_exception_policy an alias for strict_exception_policy

If none of the above suit your needs, you're free to create your own. Here is one where use the logging function object defined above as a component in a loose exception policy which logs any arithmetic errors and ignores any other types of errors.

// logging policy
// log arithmetic errors but ignore them and continue to execute
// implementation defined and undefined behavior is just executed
// without logging.

using logging_exception_policy = exception_policy<
    log_runtime_exception,    // arithmetic error
    ignore_exception,         // implementation defined behavior
    ignore_exception,         // undefined behavior
    ignore_exception          // uninitialized value


#include <boost/numeric/safe_numerics/exception_policies.hpp>