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: 19 Sep 93 21:39:39 GMT
From: agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!d
arwin.sura.net!seas.gwu.edu!mfeldman@ucbvax.Berkeley.EDU  (Michael Feldman)
Subject: Re: Comparison of Ada and C++ exceptions?
Message-ID: <1993Sep19.213939.4015@seas.gwu.edu>
List-Id: <comp.lang.ada>

In article <2790je$4en@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.lang.ada> Dale Stanbrough <dale@goanna.cs.rmit.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. 
>
>The C++ exception is an object, and I have often wanted to pass along
>some information that describes the problem.  Cf. the UNIX "exception"
>type that is used for problems detected in math routines.
>
>The exception-is-an-object idea also has the benefit that you can
>group exceptions by inheritance.  If you have
>
>	class MATHERROR ....
>	class OVERFLOW : public MATHERROR ....
>	class ZERODIVIDE : public MATHERROR ....
>	class DOMAINERROR : public MATHERROR ....
>
>You can either decide to catch overflows separately, or any math
>error, or a combination thereof:
>
>	catch (OVERFLOW) ....
>	catch (MATHERROR) ....	-- other math errors
>
>This is quite nice.

I agree. One of these days I will study C++ propagation/handling semantics
and see how it compares to Ada. But treating exceptions as real objects
is a good idea.

Mike Feldman