[jira] Commented: (AXISCPP-477) Inconsistent call::uninitialize when throwing faults from stubs

["Fred Preston (JIRA)" <ax...@ws.apache.org>]

     [ http://issues.apache.org/jira/browse/AXISCPP-477?page=comments#action_61367 ]
     
Fred Preston commented on AXISCPP-477:
--------------------------------------

Hi Mark,
I tried this in Windows and I could not produce anything other than the following sequence...
If I set a breakpoint on the destructors for 'Stub' and 'Call' then they where only called at the catch statement. This is borne out by the stack.

axiscpp::Stub::~Stub() line 46
MathOps::~MathOps() line 40 + 36 bytes
main(int 2, char * * 0x00321950) line 61
mainCRTStartup() line 206 + 25 bytes
KERNEL32! 7c59893d()

The code at line 46 in Stub is:
44:Stub::~Stub()
45:{
46:    delete m_pCall;
47:	m_pCall = NULL;

The code at line 40 in MathOps is:
38:MathOps::~MathOps()
39:{
40:}

The code at line 61 in main is:
53:try
54:{
55:  MathOps ws(endpoint);
56:  cout << "Trying to " << op << " " << i1 << " by " << i2 << endl;
57:  iResult = ws.div(i1, i2);		
58:  cout << "Result is " << iResult << endl;
59:  bSuccess = true;
60:}
61:catch(DivByZeroStruct& dbzs)
62:{

I would have expected the MathOps object to go out of scope on the 'catch' line.  This would automatically cause the destructors to be called on 'stub' and then 'call' (which contains the unInitialize() call) objects.

Can you give an example of what you have described?

> Inconsistent call::uninitialize when throwing faults from stubs
> ---------------------------------------------------------------
>
>          Key: AXISCPP-477
>          URL: http://issues.apache.org/jira/browse/AXISCPP-477
>      Project: Axis-C++
>         Type: Bug
>   Components: Client - Stub
>     Reporter: Mark Whitlock
>     Assignee: Mark Whitlock

>
> When the generated stub catches AxisException (in FaultMappingTest for example) it throws exceptions back to the client application. Sometimes it calls Call::uninitialize before it throws the exception back and sometimes it doesn't. This looks wrong to me. Surely the call object should always be uninitialized before any exception is thrown back to the client application. This may not be a simple fix since uninitializing the call object may cause problems at termination when throwing some exceptions back.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.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