...one of the most highly
regarded and expertly designed C++ library projects in the
world. — Herb Sutter and Andrei
The exception policy specifies what is to occur when a safe operation cannot return a valid result. A type is an ExceptionPolicy if it has functions for handling exceptional events that occur in the course of safe numeric operations.
||A type that fulfills the requirements of an ExceptionPolicy|
|e||A code from
|message||A const char * which refers to a text message about the cause of an exception|
Whenever an operation yield an invalid result, one of the following functions will be invoked.
|Expression||Return Value||Invoked when:|
||void||The operation cannot produce valid arithmetic result such as overflows, divide by zero, etc.|
||void||The result is undefined by the C++ standard|
||void||The result depends upon implementation defined behavior according to the C++ standard|
||void||A variable is not initialized|
This function is used to invoke the exception handling policy for a particular exception code.
template<class EP> constexpr void dispatch<EP>(const boost::numeric::safe_numerics_error & e, char const * const & msg);
The library header
contains a number of pre-made exception policies:
Throw on arithmetic errors, ignore other errors. Some applications ignore these issues and still work and we don't want to update them.
Same as above in that it doesn't check for various undefined behaviors but traps at compile time for hard arithmetic errors. This policy would be suitable for older embedded systems which depend on bit manipulation operations to work.
Permit just about anything, throw at runtime on any kind of error. Recommended for new code. Check everything at compile time if possible and runtime if necessary. Trap or Throw as appropriate. Should guarantee code to be portable across architectures.
Same as above but requires code to be written in such a way as to make it impossible for errors to occur. This naturally will require extra coding effort but might be justified for embedded and/or safety critical systems.
strict_exception_policy, One would use
this first. After experimentation, one might switch to one of the
above policies or perhaps use a custom policy.