11.1 Exception Declarations
This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue
exception_declaration declares a name for an exception.
exception_declaration declares a name for a different exception. If a generic unit includes an
exception_declarations implicitly generated by different instantiations of the generic unit refer to distinct exceptions (but all have the same
defining_identifier). The particular exception denoted by an exception name is determined at compilation time and is the same regardless of how many times the
exception_declaration is elaborated.
We considered removing this requirement inside generic bodies, because it is an implementation burden for implementations that wish to share code among several instances. In the end, it was decided that it would introduce too much implementation dependence.
Hence, if an
exception_declaration occurs in a recursive subprogram, the exception name denotes the same exception for all invocations of the recursive subprogram. The reason for this rule is that we allow an exception occurrence to propagate out of its declaration's innermost containing master; if exceptions were created by their declarations like other entities, they would presumably be destroyed upon leaving the master; we would have to do something special to prevent them from propagating to places where they no longer exist.
Exception identities are unique across all partitions of a program.
The predefined exceptions are the ones declared in the declaration of package Standard: Constraint_Error, Program_Error, Storage_Error, and Tasking_Error[; one of them is raised when a language-defined check fails.]
The exceptions declared in the language-defined package IO_Exceptions, for example, are not predefined.
The elaboration of an
exception_declaration has no effect.
The execution of any construct raises Storage_Error if there is insufficient storage for that execution. The amount of storage necessary for the execution of constructs is unspecified.
Note that any execution whatsoever can raise Storage_Error. This allows much implementation freedom in storage management.
Examples of user-defined exception declarations:
Singular : exception;
Error : exception;
Overflow, Underflow : exception;
Inconsistencies With Ada 83
The exception Numeric_Error is now defined in the Obsolescent features Annex, as a rename of Constraint_Error. All checks that raise Numeric_Error in Ada 83 instead raise Constraint_Error in Ada 95. To increase upward compatibility, we also changed the rules to allow the same exception to be named more than once by a given handler. Thus, “when Constraint_Error | Numeric_Error =>” will remain legal in Ada 95, even though Constraint_Error and Numeric_Error now denote the same exception. However, it will not be legal to have separate handlers for Constraint_Error and Numeric_Error. This change is inconsistent in the rare case that an existing program explicitly raises Numeric_Error at a point where there is a handler for Constraint_Error; the exception will now be caught by that handler.