From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a3ca574fc2007430
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Ada and Automotive Industry
Date: 1996/12/18
Message-ID: <dewar.850929677@merv>#1/1
X-Deja-AN: 204771811
references: <mazzanti-0512961053010001@131.114.200.115>
 <EACHUS.96Dec10195317@spectre.mitre.org>
 <32B197A6.2781E494@escmail.orl.lmco.com> <dewar.850626633@merv>
 <E2L8Ap.HCs@world.std.com>
organization: New York University
newsgroups: comp.lang.ada
Date: 1996-12-18T00:00:00+00:00
List-Id: <comp.lang.ada>


Bob Duff said

"Just to clarify: 11.6 applies only to language-defined checks, not
explicit raise statements like "raise Constraint_Error;".  But I agree
with Robert that "raise Constraint_Error;" is unlikely to be a good idea
in most cases."


I disagree. It is often quite appropriate. Suppose you wrote a little
package for giving saturation type semantics on ordinary arithmetic
(overflow transfomed to max or min value as appropraite). You might
still very well want to diagnose division by zero as an error, and
raising constraint error would seem a perfectly good way of doing it.