CONSTRAINT_ERROR is raised instead of NUMERIC_ERROR AI-00876/01 1 92-12-08 BI CE | !standard 11.01 (06) 92-12-08 AI-00876/01 !class binding interpretation 90-03-14 | !status ARG-approved (9-2-1) 89-10-25 (pending editorial review) | !status work-item 89-10-25 | !status received 89-10-25 | !topic CONSTRAINT_ERROR is raised instead of NUMERIC_ERROR | | !summary 92-12-08 | | CONSTRAINT_ERROR is raised by the execution of a predefined numeric operation | that cannot deliver a correct result. | | !question 92-12-08 | | AI-00387, approved by WG 9 on 86-05-09, says: | | Where the Standard requires that NUMERIC_ERROR be raised (other than | by a raise statement), CONSTRAINT_ERROR should be raised instead. | | This recommendation is non-binding. It is anticipated that in the | future, although NUMERIC_ERROR will remain as a predefined exception, | no predefined operation will be required to raise it; CONSTRAINT_ | ERROR will be required instead. | | Given that this recommended interpretation has been in place for six years, | is it not time to specify that implementations should always raise | CONSTRAINT_ERROR when the execution of a predefined numeric operation cannot | deliver a correct result? | | !recommendation 92-12-08 | | CONSTRAINT_ERROR is raised by the execution of a predefined numeric operation | that cannot deliver a correct result. | | !discussion 92-12-08 | | Given that Ada 9X will be supporting this recommendation, given that | implementers have been encouraged to follow it for several years, and given | that the widespread distribution of the ANNOTATED ADA REFERENCE MANUAL has | made this recommendation widely known, it is now time to follow through on | the original intent of AI-00387 by making this interpretation binding. CONSTRAINT_ERROR is raised instead of NUMERIC_ERROR AI-00876/01 2 92-12-08 BI CE | !appendix 92-12-08 ***************************************************************************** !section 11.01 (06) Randall Brukardt/RR Software 90-02-15 83-01367 | !version 1983 !topic Reversing AI-00387 I have never agreed with the recommendation of this AI, but that was not an issue as long as it was a nonbinding interpretation. Making this a binding interpretation means I must voice my objections. In addition, I think that there are good reasons not to change this to a binding interpretation; from the length of the discussion in the minutes, I think that the ramifications of this change were considered. First, my objections to the original AI. I do agree with the need to blur the line between Numeric_Error and Constraint_Error. I do not agree with the conclusion therefore to never allow Numeric_Error to be raised. That is going much further than necessary to solve the problem. Simply put, the Numeric_Error exception carries useful information about the nature of the problem in specialized instances. Run-of-the-mill code should in fact test for both; but there are cases where it is useful by itself. It also provides useful debugging information within the language; debugging is an important activity, of course -- otherwise we might as well just have 'Error' and avoid cluttering up the name space. Assuming that the AI is not changed, it still is not a good idea to make it binding at this time. AI's are not well known in the Ada community. A lot of Ada programmers have never heard of the ARG. We spend a lot of time explaining AI-0051 to programmers. They call us, claiming our I/O is broken. We explain that it follows the standard exactly; they claim that the standard does not talk about how integer literals are read, and we end up explaining AI-0051, the ARG, and the whole process to them. We'd get 10 times as many calls if AI-0387 is made binding, because it directly contradicts the ARM. Worse, many dozens of Ada books, courses, and Ada trainers will make the same mistake. So the poor Ada user, for which everything they own (except the compiler) says that Numeric_Error is raised, will call us to complain. Sure, it will be right there in the manual; but does anyone actually read manuals? Certainly plenty of our users don't; and I doubt that we are atypical. I don't believe it is right for the vendors to support the full cost of this education effort. Another problem is the potential breaking of a lot of code. Certainly the code is poorly written, but breaking it at this time would not be a positive thing. If Numeric_Error was completely removed, users would get error messages when it was encountered in the code. Such a removal would mess up backward compatibility, but would help cut down on the number of broken programs. CONSTRAINT_ERROR is raised instead of NUMERIC_ERROR AI-00876/01 3 92-12-08 BI CE Given that this AI is sooner or later going to be made binding, is there a better time to do it? I say certainly - it should be made as part of the Ada 9x effort. At that time, users are going to expect that their code may need some work. Also, Numeric_Error can be completely removed, eliminating errors in poorly written but functional existing code. Lastly, users are unlikely to believe old, pre-9x Ada books in preference to new books and compilers. Therefore, I believe this change should be deferred to Ada 9x, if it is done at all. | ***************************************************************************** | | !section 11.01 (06) J. Goodenough 92-12-08 | !version 1983 | !topic Minutes of Oct 89 ARG meeting | | The ARG agreed (9-2-1) that a commentary should be prepared recommending that | AI-00387/05 be reclassified as a binding interpretation and that ACVC tests | be prepared to enforce this interpretation.