axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: FW: Exception model (more thoughts)
Date Tue, 12 Jul 2005 08:11:39 GMT
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