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: bobduff@world.std.com (Robert A Duff)
Subject: Re: Ada and Automotive Industry
Date: 1996/12/19
Message-ID: <E2o1M9.3AI@world.std.com>#1/1
X-Deja-AN: 204921076
references: <mazzanti-0512961053010001@131.114.200.115> <dewar.850929677@merv>
 <E2MvrB.Ip7@world.std.com> <32B8AF89.CA@lmtas.lmco.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-12-19T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <32B8AF89.CA@lmtas.lmco.com>,
Ken Garlington  <GarlingtonKE@lmtas.lmco.com> wrote:
>Actually, I like to raise Program_Error when this happens. Its' roughly
>equivalent to the "WTF?" message we used to generate in our FORTRAN
>tools
>when we reached a condition in the program that "shouldn't happen."

Fine, but Robert Dewar's example was divide-by-zero in a user-defined
arithmetic package, and his point was that this divide-by-zero is
analogous to the predefined divide-by-zero, so C_E makes sense.  I
suspect Robert would extend that reasoning to say that C_E makes sense
whenever the error is conceptually "violating a constraint".  P_E
doesn't make much sense for divide by zero.

- Bob