Issue 3050: Awkward way of unmarshaling exceptions (messaging-rtf)
Source: Comtech EF Data Corporation (Dr. Shahzad Aslam-Mir, s786am(at)hotmail.com)
Nature: Uncategorized Issue
Severity: 
Summary:        There is a somwhat awkward way of unmarshaling exceptions.  The
client must
open a try block, call a raise method, and catch the unmarshaled
exception.
 This seems unnecessary.  There's no reason the exception can't be
unmarshaled in
the normal way.  Consequently in order to support the current model
value types are
unnecessarily required.
Resolution: close this issue
Revised Text: 
Actions taken:
November 17, 1999: received issue
January 9, 2001: closed issue
Discussion: 
This was discussed for a long long time in a face to face meeting about 6 months ago. What is the "normal" way of raising an exception in a language neutral way when you are not in fact calling an operation but it is being called on you. 
The only other possibility that was proposed was that the exception could be embedded within an any, which seems 
to be possible now, but this was thought to be equally clunky, and probably undesirable since many uses of AMI are likely to be in minimum footprint environments where it is desirable to have the possibility to leave out "any" if it is not used. 
Close this issue, unless somebody comes up with a proposal that works. 

End of Annotations:=====
Date: Wed, 17 Nov 1999 16:21:35 -0800
From: Shahzad Aslam-Mir <sam@expersoft.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: issues@omg.org, Jishnu Mukerji <jis@fpk.hp.com>
Subject: AMI revision task force issues
Content-Type: multipart/mixed;
 boundary="------------5E665364E22E405C5A91FF1A"
X-UIDL: D&H!!:1Ge9j:J!!Y"4!!

Hi,
    I do not know how to direct the following issues, but we feel that
these merit concern and some re-examination in the Async specification
-
Please could these be conveyed to the appropriate people, as I do not
know where to send these: Here are our concerns:

-       There is a somwhat awkward way of unmarshaling exceptions.
The
client must
open a try block, call a raise method, and catch the unmarshaled
exception.
 This seems unnecessary.  There's no reason the exception can't be
unmarshaled in
the normal way.  Consequently in order to support the current model
value types are
unnecessarily required.

From: Bill Binko <Bill.Binko@trcinc.com>
To: Messaging-Rtf <messaging-rtf@omg.org>
Subject: Discussion Issue 3050: Awkward way of unmarshaling exceptions
(me
	ssaging-rtf)
Date: Wed, 22 Mar 2000 12:29:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: m%g!!;>&!!W9~!!QD>!!

I agree that the spec does as well as we can at this point.
 
However, is there a clear reason that exceptions cannot be parameters?
 They
are marshalled (almost) just like structs and it would clean up a
great
deal!  In addition, I think that every mapped language that has native
exceptions allows them as parameters!
 
I know this is outside of OUR RTF, but does anyone know why this
change
hasn't been made in the core?
 
Just wondering.
 
Binko