axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samisa Abeysinghe" <SAbeysin...@virtusa.com>
Subject RE: FW: Exception model (more thoughts)
Date Tue, 12 Jul 2005 08:45:09 GMT
Yes please...

Samisa...

-----Original Message-----
From: Dushshantha Chandradasa [mailto:dchandradasa@virtusa.com] 
Sent: Tuesday, July 12, 2005 2:18 PM
To: Apache AXIS C Developers List; Samisa Abeysinghe
Subject: RE: FW: Exception model (more thoughts)

No I didn't change it. But we can do that without making any change in
the model. 

Shall we go for it??

Regards,
Dushshantha

-----Original Message-----
From: Samisa Abeysinghe [mailto:samisa.abeysinghe@gmail.com] 
Sent: Tuesday, July 12, 2005 2:12 PM
To: Apache AXIS C Developers List
Subject: Re: FW: Exception model (more thoughts)

Hi Dushshantha,
    Have you looked into "coverting m_sMessage to a const char*
instead of a std::string" as Mark had suggested?

Thanks,
Samisa...

On 7/4/05, Mark Whitlock <mark_whitlock@uk.ibm.com> wrote:
> 
> 
> 
> 
> Hi Dushshantha,
> STL is being removed from the Axis C++ external API (AXISCPP-681 and
> others). If you are OK with this, please could you make m_sMessage a
const
> char* instead of a std::string? I realise this involves more code but
it
> helps to avoid incompatibilities in the STL.
> Thanks,
> Mark
> Mark Whitlock
> IBM
> 
> ----- Forwarded by Mark Whitlock/UK/IBM on 04/07/2005 14:56 -----
> 
>              Mark
>              Whitlock/UK/IBM
>
To
>              04/07/2005 14:41          axis-c-dev@ws.apache.org
>
cc
> 
>
Subject
>                                        Re: FW: Exception model
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Dushshantha,
> Try adding in
> ws-axis\c\tools\org\apache\axis\tools\cbindings\cbindinggenerator.conf
the
> line
> excludemethod=AxisException::AxisException
> 
> The problem is that the tool that generates the header files for the C
> bindings does not support overloaded constructors. So the proper fix
is to
> change
> ws-axis\c\tools\org\apache\axis\tools\cbindings\CBindingGenerator.java
> generateFunctionPrototype to support overloaded constructors. There is
> support in there for overloading other methods, but this needs some
fixing
> as well. I hope to work on this whole area in the autumn.
> 
> The simple workaround is to add to
> ws-axis\c\tools\org\apache\axis\tools\cbindings\cbindinggenerator.conf
the
> line excludemethod=AxisException::AxisException which should stop C
> bindings being generated for any AxisException constructor. If that
doesn't
> work, exclude the AxisException file instead. This is probably a good
fix
> since I can't see why C applications would need to construct
> AxisExceptions.
> Please get back to me if you still have problems,
> Mark
> Mark Whitlock
> IBM
> 
> ----- Forwarded by Mark Whitlock/UK/IBM on 04/07/2005 13:38 -----
> 
>              "Dushshantha
>              Chandradasa"
>              <dchandradasa@vir
To
>              tusa.com>                 "Apache AXIS C Developers List"
>                                        <axis-c-dev@ws.apache.org>
>              04/07/2005 11:11
cc
> 
>
Subject
>              Please respond to         FW: Exception model
>               "Apache AXIS C
>              Developers List"
> 
> 
> 
> 
> 
> 
> 
> 
> Hi All,
> 
> I tried modifying the current exception model to the one that Samisa
> explained below. I introduced 2 constructors to AxisException base
class;
> one is a copy constructor with following code
> 
> AxisException(const AxisException&
e):m_iExceptionCode(e.m_iExceptionCode),
> m_sMessage(e.m_sMessage){};
> 
> And the other one is with following code
> 
> AxisException(const int iExceptionCode, const char* pcMessage =
> NULL):m_iExceptionCode(iExceptionCode)
>             {
>                         if(pcMessage)
>                                     m_sMessage =
std::string(pcMessage);
>                         else
>                                     m_sMessage = "";
>             }
> 
> And  changed the child inherited classes accordingly.
> 
> But this change leads me to have C support break with following Error
> messages.
> 
> 
>        [cc] AxisExceptionC.cpp
>        [cc] C:\obj\include\axis/AxisException.h(180) : error C2733:
second
> C lin
> kage of overloaded function 'axiscCreateAxisException' not allowed
>        [cc]         C:\obj\include\axis/AxisException.h(179) : see
> declaration o
> f 'axiscCreateAxisException'
>        [cc] C:\obj\include\axis/AxisException.h(190) : error C2143:
syntax
> error
>  : missing ',' before '*'
>        [cc] C:\obj\include\axis/AxisException.h(190) : error C2059:
syntax
> error
>  : '*'
>        [cc] C:\obj\include\axis/AxisException.h(190) : error C2733:
second
> C lin
> kage of overloaded function 'axiscCreateAxisException' not allowed
>        [cc]         C:\obj\include\axis/AxisException.h(190) : see
> declaration o
> f 'axiscCreateAxisException'
>        [cc] Generating Code...
> 
> BUILD FAILED
> C:\axiscpp\ws-axis\c\build.xml:213: The following error occurred while
> executing
>  this line:
> C:\axiscpp\ws-axis\c\build\buildTools.xml:85: cl failed with return
code 2
> 
> 
> Any thoughts please..
> 
> Regards,
> Dushshantha
> 
> From: Samisa Abeysinghe [mailto:SAbeysinghe@virtusa.com]
> Sent: Monday, July 04, 2005 11:22 AM
> To: Apache AXIS C Developers List
> Subject: Exception model
> 
> Hi All,
>             PFA the class diagram of current exception model we have.
> 
>             Looking into the several issues we have against the
exception
> model, it is worth considering a re-arrangement here.
> http://issues.apache.org/jira/browse/AXISCPP-707
> http://issues.apache.org/jira/browse/AXISCPP-721
> http://issues.apache.org/jira/browse/AXISCPP-722
> 
>             The idea is *very* simple here.  (basic OO stuff)
>          1.       We have m_sMessage and m_iExceptionCode as data
members
>          in all the derived classes - move them to base class. Move
the
>          access methods to the base class as well.
>          2.       Drop all processException() methods and move the
logic to
>          constructor
>          3.       getMessage() methods in the derived classes do not
get
>          the message rather return the message corresponding to the
>          exception code. Hence rename getMessage()
>          getMessageForExceptionCode()
>          4.       We have "what()" in the base class to get the error
>          message. This is a virtual method inherited from the
'exception'
>          class hence we cannot change the naming. However, better to
have a
>          more sensible name like getMessage to wrap this
>          5.       There are too many constructors in the derived
classes, I
>          would like only two constructors for each class
>                a.       Copy constructor
>                b.       Constructor with 2 parameters, exception code
and
>                message, with message defaulting to null.
ExceptionClass(int
>                code, char* msg = null)
> 
> Thanks,
> Samisa...
> 
>  [attachment "ExceptionModel_before.JPG" deleted by Mark
Whitlock/UK/IBM]

Mime
View raw message