Exceptional conditions

For each condition, the corresponding signal in the context is given, along with the defined result. The value of the trap-enabler for each signal in the context determines whether an operation is completed after the condition is detected or whether the condition is trapped and hence not necessarily completed (see IEEE 854 §8).

This specification does not define the manner in which exceptions are reported or handled. For example, in a object-oriented language, an Arithmetic Exception object might be signalled or thrown, whereas in a calculator application an error message or other indication might be displayed.

The following exceptional conditions can occur:

Conversion syntax

This occurs and signals invalid-operation if an string is being converted to a number and it does not conform to the numeric string syntax. The result is [0,qNaN].

Division by zero

This occurs and signals division-by-zero if division by zero was attempted (during a divide-integer or divide operation, or a power operation with negative right-hand operand), and the dividend was not zero.

The result of the operation is [sign,inf], where sign is the sign of the dividend.

Division impossible

This occurs and signals invalid-operation if the integer result of a divide-integer or remainder operation had too many digits (would be longer than precision). The result is [0,qNaN].

Division undefined

This occurs and signals invalid-operation if division by zero was attempted (during a divide-integer, divide, or remainder operation), and the dividend is also zero. The result is [0,qNaN].

Inexact

This occurs and signals inexact whenever the result of an operation is not exact (that is, it needed to be rounded and any discarded digits were non-zero), or if an overflow or underflow condition occurs. The result in all cases is unchanged.

The inexact signal may be tested (or trapped) to determine if a given operation (or sequence of operations) was inexact.^[1] 

Insufficient storage

For many implementations, storage is needed for calculations and intermediate results, and on occasion an arithmetic operation may fail due to lack of storage. This is considered an operating environment error, which can be either be handled as appropriate for the environment, or treated as an Invalid operation condition. The result is [0,qNaN].

Invalid context

This occurs and signals invalid-operation if an invalid context was detected during an operation. This can occur if contexts are not checked on creation and either the precision exceeds the capability of the underlying concrete representation or an unknown or unsupported rounding was specified. These aspects of the context need only be checked when the values are required to be used. The result is [0,qNaN].

Invalid operation

This occurs and signals invalid-operation if:

• an operand to an operation is [0,sNaN] (signaling NaN)
• an attempt is made to add [0,inf] to [1,inf] during an addition or subtraction operation
• an attempt is made to multiply 0 by [0,inf] or [1,inf]
• an attempt is made to divide either [0,inf] or [1,inf] by either [0,inf] or [1,inf]
• the divisor for a remainder operation is zero
• the dividend for a remainder operation is either [0,inf] or [1,inf]
• the right-hand operand of the rescale operation has a non-zero fractional part, or is outside the permitted range
• the operand of the square-root operation has a sign of 1 and a non-zero coefficient
• both operands of the power operation are zero, or the right-hand operand has a non-zero fractional part, or has more than 9 digits, or is infinite
• An operand is invalid. For example, certain values of concrete representations may not correspond to numbers; an implementation is permitted (but is not required) to detect these invalid values and raise this condition.

The result of the operation after any of these invalid operations is [0,qNaN].

Overflow

This occurs and signals overflow if the adjusted exponent of a result (from a conversion or from an operation that is not an attempt to divide by zero) would be greater than the largest value that can be handled by the implementation (the value E_max). It also occurs if a rescale operation would require greater precision than is available.

The result depends on the rounding mode:

• For round-half-up and round-half-even (and for round-half-down and round-up, if implemented), the result of the operation is [sign,inf], where sign is the sign of the intermediate result.
• For round-down, the result is the largest finite number that can be represented in the current precision, with the sign of the intermediate result.
• For round-ceiling, the result is the same as for round-down if the sign of the intermediate result is 1, or is [0,inf] otherwise.
• For round-floor, the result is the same as for round-down if the sign of the intermediate result is 0, or is [1,inf] otherwise.

In all cases, Inexact and Rounded will also be raised.

Note: IEEE 854 §7.3 requires that the result delivered to a trap handler be different, depending on whether the overflow was the result of a conversion or of an arithmetic operation. This specification deviates from IEEE 854 in this respect; however, an implementation could comply with IEEE 854 by providing a separate mechanism for the special result to a trap handler.

Rounded

This occurs and signals rounded whenever the result of an operation is rounded (that is, some zero or non-zero digits were discarded from the coefficient), or if an overflow or underflow condition occurs. The result in all cases is unchanged.

The rounded signal may be tested (or trapped) to determine if a given operation (or sequence of operations) caused a loss of precision.

Subnormal

This occurs and signals subnormal whenever the result of a conversion or operation is subnormal (that is, its adjusted exponent is less than E_min, before any rounding). The result in all cases is unchanged.

The subnormal signal may be tested (or trapped) to determine if a given or operation (or sequence of operations) yielded a subnormal result.

Underflow

This occurs and signals underflow if a result is inexact and the adjusted exponent of the result would be smaller (more negative) than the smallest value that can be handled by the implementation (the value E_min). That is, the result is both inexact and subnormal.^[2] 

The result after an underflow will be a subnormal number rounded, if necessary, so that its exponent is not less than E_tiny. This may result in 0 with the sign of the intermediate result and an exponent of E_tiny.

In all cases, Inexact, Rounded, and Subnormal will also be raised.

Note: IEEE 854 §7.4 requires that the result delivered to a trap handler be different, depending on whether the underflow was the result of a conversion or of an arithmetic operation. This specification deviates from IEEE 854 in this respect; however, an implementation could comply with IEEE 854 by providing a separate mechanism for the result to a trap handler.

The Inexact, Rounded, and Subnormal conditions can coincide with each other or with other conditions. In these cases then any trap enabled for another condition takes precedence over (is handled before) all of these, any Subnormal trap takes precedence over Inexact, and any Inexact trap takes precedence over Rounded.

It is recommended that implementations distinguish the different conditions listed above, and also provide additional information about exceptional conditions where possible (for example, the operation being attempted and the values of the operand or operands involved – see also IEEE 854 §8.1).