C++ SDO spec portability: SDORuntimeException off-spec member functions
-----------------------------------------------------------------------

                 Key: TUSCANY-1366
                 URL: https://issues.apache.org/jira/browse/TUSCANY-1366
             Project: Tuscany
          Issue Type: Improvement
          Components: C++ SDO
    Affects Versions: Cpp-M3
         Environment: portability issue -- all platforms
            Reporter: Michael Yoder


Tuscany C++ SDO specification class SDORuntimeException has off-spec member 
functions used by SCA (shown in the e-mail thread below). It would seem that 
for portability these should be taken internal to Tuscany SDO, or submitted to 
the spec committee.

-----Original Message-----
From: Michael Yoder 
Sent: Thursday, June 21, 2007 7:37 PM
To: 'tuscany-dev@ws.apache.org'
Subject: RE: C++ SDO spec compliance/portability: SDORuntimeException

Thanks Pete,

Yes, these issues I am putting together and posting came up when doing a 
portability study using HydraSDO to build Tuscany SCA. Since the SDO spec is 
separate from SCA, we were thinking this would be a good goal. That seems to 
mean making them internal to Tuscany SDO or taking them to the committee.

Michael

-----Original Message-----
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 9:02 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec compliance/portability: SDORuntimeException

Michael,

An interesting set of questions! I'm not convinced that adding methods to the 
spec api classes is a compliance issue (in fact it may be impossible to 
implement without modifying the spec apis ... constructors etc.) but it could 
be a portability issue if it is not clear that the methods are implementation 
specific.

The methods below are added so that an SDORuntimeException can contain a 
"stack" of locations indicating where it was thrown/rethrown etc.. These are 
only used within the Tuscany implementation so I guess could be moved to 
protected and make the classes that use them friends?? I'm not sure how useful 
these are anyway but the exception class pre-dates it being used for 
SDORuntimeException.


There are also methods to allow simple streaming:

catch(SDORuntimeException& e)
{
   cout << e;
}

I like the simplicity of this but I guess we could write an SDOUtils method to 
do something similar instead.

I'm not sure if any of these should be mandated by the specification.

Cheers,


On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> The Tuscany SDO C++ class SDORuntimeException has these public member 
> functions which do not appear in the C++ 2.1 specification:
>
>
> SDO_API severity_level getSeverity() const; SDO_API void 
> setSeverity(severity_level sev); SDO_API void setMessageText(const 
> std::string& msg_text); SDO_API void setExceptionLocation(const 
> std::string& file,
>                                    unsigned long line,
>                                    const std::string& function=""); 
> SDO_API void setLocation(const std::string& file,
>                           unsigned long line,
>                           const std::string& function="");
>
> SDO_API void trace(const std::string& text="%1:\n  %3 %4 %2");
>
> SDO_API virtual ostream& PrintSelf(ostream &os) const; SDO_API friend 
> ostream& operator<< (ostream &os, const SDORuntimeException &except);
>
>
> What's the rational behind these additional member functions? Would it 
> be appropriate to file a bug to have them removed from the public API?
> Or alternatively a bug for them to be submitted to the spec committee?
>
> Thanks,
>
> Michael Yoder
> Software Developer
> Rogue Wave Software
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Pete


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to