Contents   Index   Previous   Next


1.1.5 Classification of Errors

Implementation Requirements

1
   The language definition classifies errors into several different categories:
2
3
4
4.a
Ramification: See, for example, 10.1.3, ``Subunits of Compilation Units'', for some errors that are detected only after compilation. Implementations are allowed, but not required, to detect post compilation rules at compile time when possible.
5
6
7
8
9
10
10.a
Ramification: Executions are erroneous, not programs or parts of programs. Once something erroneous happens, the execution of the entire program is erroneous from that point on, and potentially before given possible reorderings permitted by 11.6 and elsewhere. We cannot limit it to just one partition, since partitions are not required to live in separate address spaces. (But implementations are encouraged to limit it as much as possible.)
10.b
Suppose a program contains a pair of things that will be executed ``in an arbitrary order.'' It is possible that one order will result in something sensible, whereas the other order will result in erroneous execution. If the implementation happens to choose the first order, then the execution is not erroneous. This may seem odd, but it is not harmful.
10.c
Saying that something is erroneous is semantically equivalent to saying that the behavior is unspecified. However, ``erroneous'' has a slightly more disapproving flavor.

Implementation Permissions

11
    [{mode of operation (nonstandard)} {nonstandard mode} An implementation may provide nonstandard modes of operation. Typically these modes would be selected by a pragma or by a command line switch when the compiler is invoked. When operating in a nonstandard mode, the implementation may reject compilation_units that do not conform to additional requirements associated with the mode, such as an excessive number of warnings or violation of coding style guidelines. Similarly, in a nonstandard mode, the implementation may apply special optimizations or alternative algorithms that are only meaningful for programs that satisfy certain criteria specified by the implementation. {mode of operation (standard)} {standard mode} In any case, an implementation shall support a standard mode that conforms to the requirements of this International Standard; in particular, in the standard mode, all legal compilation_units shall be accepted.]
11.a
Discussion: These permissions are designed to authorize explicitly the support for alternative modes. Of course, nothing we say can prevent them anyway, but this (redundant) paragraph is designed to indicate that such alternative modes are in some sense ``approved'' and even encouraged where they serve the specialized needs of a given user community, so long as the standard mode, designed to foster maximum portability, is always available.

Implementation Advice

12
    {Program_Error (raised by failure of run-time check)} If an implementation detects a bounded error or erroneous execution, it should raise Program_Error.

Wording Changes from Ada 83

12.a
Some situations that are erroneous in Ada 83 are no longer errors at all. For example, depending on the parameter passing mechanism when unspecified is possibly non-portable, but not erroneous.
12.b
Other situations that are erroneous in Ada 83 are changed to be bounded errors. In particular, evaluating an uninitialized scalar variable is a bounded error. {Program_Error (raised by failure of run-time check)} The possible results are to raise Program_Error (as always), or to produce a machine-representable value (which might not be in the subtype of the variable). {Constraint_Error (raised by failure of run-time check)} Violating a Range_Check or Overflow_Check raises Constraint_Error, even if the value came from an uninitialized variable. This means that optimizers can no longer ``assume'' that all variables are initialized within their subtype's range. Violating a check that is suppressed remains erroneous.
12.c
The ``incorrect order dependences'' category of errors is removed. All such situations are simply considered potential non-portabilities. This category was removed due to the difficulty of defining what it means for two executions to have a ``different effect.'' For example, if a function with a side-effect is called twice in a single expression, it is not in principle possible for the compiler to decide whether the correctness of the resulting program depends on the order of execution of the two function calls. A compile time warning might be appropriate, but raising of Program_Error at run time would not be.

Contents   Index   Previous   Next   Legal