Decimal Arithmetic Specification, version 1.08
Copyright (c) IBM Corporation, 2003. All rights reserved.
8 Jan 2003
[previous | contents | next]

Exceptional conditions

This section lists, in the abstract, the exceptional conditions that may arise during the operations defined in this specification.

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:

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 Emax). It also occurs if a rescale operation would require greater precision than is available.

The result depends on the rounding mode:

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 Emin, 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 Emin). 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 Etiny. This may result in 0 with the sign of the intermediate result and an exponent of Etiny.

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).


Footnotes:
[1] Note that IEEE 854 is inconsistent in its treatment of Inexact in that it states in 7 that the Inexact exception can coincide with Underflow, but does not allow the possibility of Underflow signaling Inexact in 7.5. It is assumed that the latter is an accidental omission.
[2] See IEEE 854 7.4.

[previous | contents | next]