Comparison of Ada and C++ exceptions?

Comparison of Ada and C++ exceptions?

[munnari.oz.au!bruce.cs.monash.edu.au!monu6!aggedor.rmit.OZ.AU!root]

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.

Is it useful to be able to pass data along with an exception?

Dale Stanbrough
RMIT, Melbourne Australia
dale@goanna.cs.rmit.edu.au

Re: Comparison of Ada and C++ exceptions?

[Dag Bruck]

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.

		-- Dag

Re: Comparison of Ada and C++ exceptions?

[pipex!zaphod.crihan.fr!vishnu.jussieu.fr!univ-lyon1.fr!scsing.switch.ch!e]

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

Re: Comparison of Ada and C++ exceptions?

[David Emery]

One version of the POSIX/Ada binding used separate exceptions for each
POSIX error condition.  However, for the reasons Mats mentioned, this
was changed to a single exception (POSIX_ERROR) and a set of
operations to get the error code,  
	type ERROR_CODE is <implementation defined integer>;
	function GET_ERROR_CODE return ERROR_CODE;
	function IS_POSIX_ERROR (ERROR : ERROR_CODE) return BOOLEAN;
	function IMAGE (ERROR : ERROR_CODE) return STRING;
	
	NO_ERROR : constant ERROR_CODE := 0;
	ARGUMENT_LIST_TOO_LONG : constant ERROR_CODE
			       := <implementation defined static expression>;
	BAD_FILE_DESCRIPTOR    : constant ERROR_CODE
			       := <implementation defined static expression>;
	--- etc.
There is an additional requirement that the error code value be kept
on a per-task basis.  See IEEE Std. 1003.5-1992 for more information,
particularly for a discussion on why the type ERROR_CODE is an integer
type rather than a private type or enumeration type.

Now, if we had 'execption parameters' or a similar mechanism, then we
could have attached the error code to the POSIX_ERROR exception.  I
would have liked that very much, and that was a feature I was hoping
to get with 9X.

				dave

Re: Comparison of Ada and C++ exceptions?

[agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!d]

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