axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samisa Abeysinghe (JIRA)" <>
Subject [jira] Assigned: (AXISCPP-496) soap/xsd classes throw exceptions by pointer not by value
Date Wed, 02 Mar 2005 09:31:49 GMT
     [ ]

Samisa Abeysinghe reassigned AXISCPP-496:

    Assign To: Samisa Abeysinghe

> soap/xsd classes throw exceptions by pointer not by value
> ---------------------------------------------------------
>          Key: AXISCPP-496
>          URL:
>      Project: Axis-C++
>         Type: Bug
>   Components: Serialization
>     Reporter: Mark Whitlock
>     Assignee: Samisa Abeysinghe

> By chance I discovered that a lot of the classes in soap/xsd throw exceptions by pointer
rather than by value. For example (from Date.cpp)....
> throw new AxisSoapException(CLIENT_SOAP_SOAP_CONTENT_ERROR, const_cast<AxisChar*>(exceptionMessage.c_str()));
> This is different from the rest of Axis C++ which does (example taken from SoapDeSerializer.cpp)...
> (Notice the lack of "new") 
> What follows is what I think will happen, but I'm not sure so it will take some investigation.
I think samples, clients and testcases catch (AxisException &e) so they will catch an
exception reference or a exception value, but not an exception pointer. Clients would have
to catch (AxisException *e) in order to catch an exception throw using throw new AxisSoapException().
> If an exception is new'ed and then thrown, who will delete the storage? It will be up
to the client application or else there will be a storage leak.
> Also many of the methods in soap/xsd have throws(AxisSoapException) on their method prototype.
I think this means that the method will allow AxisSoapException's to be thrown OK, but any
other exceptions that are thrown will get converted to a bad_exception. So I think that AxisSoapException*'s
will become bad_exception's as well. I think it is a bad idea to put throws(AxisSoapException)
on a method prototype, since the compiler doesn't seem to check and it causes unforseen problems
at runtime.
> I discussed this problem with Adrian Dick since he wrote the code originally. He agreed
that it seems like a problem and he asked me to raise this JIRA.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message