axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Whitlock (JIRA)" <axis-c-...@ws.apache.org>
Subject [jira] Commented: (AXISCPP-216) Improve Fault handling
Date Mon, 29 Nov 2004 10:45:25 GMT
     [ http://nagoya.apache.org/jira/browse/AXISCPP-216?page=comments#action_55968 ]
     
Mark Whitlock commented on AXISCPP-216:
---------------------------------------

Copying discussion from axis-c-dev mailing list to this issue...

Damitha wrote ...

Hi Mark,
Since you are not going to do the improvments until after that 1.4 release
let's start discussing this soon after the release.
Read below
On Thu, 25 Nov 2004 16:08:02 +0000, Mark Whitlock wrote
> Hi,
> I am currently investigating AXISCPP-216 and I would like to discuss 
> it before I make any changes.
> 
> In the client, the engine throws AxisException's. If that AxisException
> describes a user fault (in the wsdl) which the web service itself has
> thrown, the generated client stubs convert that AxisException into a
> MathOpsService_AxisClientException. The MathOpsService_AxisClientException
> is a generated class that is thrown back to the client application. 
> So the FaultMappingDocClient looks like ...
> 
> try {
>  result=ws.div(i1,i2);
> } catch(MathOpsService_AxisClientException &e) {
>   ISoapFault *fault = (ISoapFault *)e.getFault();
>   faultName = fault->getCmplxFaultObjectName().c_str();
>   if (0==strcmp("DivByZeroStruct",faultName)) {
>     DivByZeroStruct *p=(DivByZeroStruct*)fault->getCmplxFaultObject()
> ;  } else ... } catch (AxisException &e) {  ... } catch (...) {  ... }
> 
> So all AxisException's which aren't faults defined in the wsdl are caught
> by the catch (AxisException&). I propose to make two small 
> improvements to this by moving AxisGenException.hpp from 
> include/axis into src/common since applications never need it.

OK 

>Also 
> I propose to hide the ISoapFault from client applications by 
> generating suitable methods on the MathOpsService_AxisClientException.....
> 
> } catch(MathOpsService_AxisClientException &e) {
>   faultName = e.getFaultName();
>   if (0==strcmp("DivByZeroStruct",faultName)) {
>     DivByZeroStruct *p=(DivByZeroStruct*)e.getFaultObject();
>   } else ...
> 
> I thought about the generated stub throwing a DivByZeroStruct 
> instead of a MathOpsService_AxisClientException.

This is good

> The DivByZeroStruct 
> would have to extend AxisException to get the other original 
> information about the fault. But I don't think this would work since 
> the fault in the wsdl could be a basic type (int or string) not a 
> complex type and so could not extend AxisException.
> 
> I expect to make these changes for 1.5 not 1.4.
> Comments?
> Mark
> Mark Whitlock
> IBM


--
Damitha Kumarage
hSenid Software International (PVT) Ltd
damitha@hSenid.lk

Lanka Software Foundation (http://www.opensource.lk)


> Improve Fault handling
> ----------------------
>
>          Key: AXISCPP-216
>          URL: http://nagoya.apache.org/jira/browse/AXISCPP-216
>      Project: Axis-C++
>         Type: Improvement
>   Components: Basic Architecture
>     Versions: 1.3 Final
>     Reporter: John Hawkins
>     Assignee: Mark Whitlock
>      Fix For: 1.4 Beta

>
> Fault handling was implemented such that any faults came back as exception. There are
however, still issues with this method and we can restructure the objects to improve the support.
There are threads on the mailing list discussing this -> http://marc.theaimsgroup.com/?l=axis-c-dev&m=109639024228932&w=2
and http://marc.theaimsgroup.com/?l=axis-c-dev&m=109774330012038&w=2.
> I think we can safely say we have not agreed on a way forward yet !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message