From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 16 Sep 93 08:45:34 GMT
From: pipex!zaphod.crihan.fr!vishnu.jussieu.fr!univ-lyon1.fr!scsing.switch.ch!e
pflnews!disuns2.epfl.ch!lglsun!madmats@uunet.uu.net  (Mats Weber)
Subject: Re: Comparison of Ada and C++ exceptions?
Message-ID: <1993Sep16.100759@lglsun.epfl.ch>
List-Id: <comp.lang.ada>

In article <275plh$smn@aggedor.rmit.OZ.AU>, Dale Stanbrough <dale@goanna.cs.rmi
t.edu.au> writes:
|> Recently I had reason to look at C++'s exception handling. I noticed that
|> each
|> exception can have associated with it some data (user defined), such as a
|> string, a pointer - in fact any object the programmer wants. 
|> 
|> I don't think Ada9x's exceptions have any such feature, and I was
|> wondering
|> what the general feeling about this was.
|> 

I think such a feature would be very useful, especially when
interfacing large non-Ada based systems, such as POSIX, where there
are many error situations that cannot easily be mapped onto
exceptions.

In POSIX, if each system error situation is mapped onto an Ada
exception, then programmers will often have to write huge exception
choices in their handlers, such as the following (which requires
reading the documentation for each possible call, even if the details
of the error doesn't matter):

exception
   when POSIX_Exceptions.IO_Error |
        POSIX_Exceptions.Invalid_File_Number |
	POSIX_Exceptions.xxx |
	POSIX_Exceptions.yyy |
	POSIX_Exceptions.zzz =>
      Do_Something;

Note: I am probably not up to date on how the POSIX exceptions are
organized, but this is just an example.

There should be some way of handling all these exceptions together,
with a single choice in the handler. A proposal for this (hierarchical
exceptions) was in a previous version of the draft 9X mapping, but was
removed. I think this proposal was very good.

Being able to attach a parameter to exceptions solves the problem in
the previous example, too.  POSIX, for example, coud then have

   type POSIX_Error_Code is (IO_Error, Invalid_File_Number, ...);
   POSIX_Error : exception (Code : POSIX_Error_Code);
	
Where each exception would be parameterized with a value of the type
POSIX_Error_Code, Which would allow handling POSIX exceptions with a
single choice and sepcializing exception handlers only when necessary.

-- 
Mats Weber
Software Engineering Lab
Swiss Federal Institute of Technology
CH-1015 Lausanne
Switzerland
e-mail: mats.weber@lglsun.epfl.ch