Why am I seeing such a delay between my catch block and my finally block 
Author Message
 Why am I seeing such a delay between my catch block and my finally block

I have an application which has along running thread.
Actually it should be in a perpetual loop.

A webservice call in the loop is giving a SOAP exception.

This exception is caught by my catch block.

I then have a finally block which I expect to do some cleanup,
and to notify the UI thread that something bad has happened.

I put some break statements into my catch and finally blocks to determine
the
latency between to two.

Concensus here was that the finally block would get called IMMEDIATELY
after the catch block was completed.

Surprise Surprise there was a huge delay!!!! At least in my de{*filter*}.

Is this just an artifact of the de{*filter*}?

Any ideas would be greatly appreciated.



Tue, 12 Apr 2005 23:13:46 GMT  
 Why am I seeing such a delay between my catch block and my finally block
Perhaps, being a SOAP call, it is waiting synchronously for the remote
server to acknowledge that the remote call has been terminated and tidied up
before execution continues? (only guessing).
Or, try printing out timer values (using milliseconds) to see if the effect
is introduced by the de{*filter*}.

Cheers,
  iGadget


Quote:
> I have an application which has along running thread.
> Actually it should be in a perpetual loop.

> A webservice call in the loop is giving a SOAP exception.

> This exception is caught by my catch block.

> I then have a finally block which I expect to do some cleanup,
> and to notify the UI thread that something bad has happened.

> I put some break statements into my catch and finally blocks to determine
> the
> latency between to two.

> Concensus here was that the finally block would get called IMMEDIATELY
> after the catch block was completed.

> Surprise Surprise there was a huge delay!!!! At least in my de{*filter*}.

> Is this just an artifact of the de{*filter*}?

> Any ideas would be greatly appreciated.



Tue, 12 Apr 2005 23:42:02 GMT  
 Why am I seeing such a delay between my catch block and my finally block
Hi,

  It may be that the de{*filter*} is trying to debug the Web Service, or get
some debugging information from it.  You should be able to tell if you run
the timing tests outside the de{*filter*}.

  - Bruce Brown.


Quote:
> Perhaps, being a SOAP call, it is waiting synchronously for the remote
> server to acknowledge that the remote call has been terminated and tidied
up
> before execution continues? (only guessing).
> Or, try printing out timer values (using milliseconds) to see if the
effect
> is introduced by the de{*filter*}.

> Cheers,
>   iGadget



> > I have an application which has along running thread.
> > Actually it should be in a perpetual loop.

> > A webservice call in the loop is giving a SOAP exception.

> > This exception is caught by my catch block.

> > I then have a finally block which I expect to do some cleanup,
> > and to notify the UI thread that something bad has happened.

> > I put some break statements into my catch and finally blocks to
determine
> > the
> > latency between to two.

> > Concensus here was that the finally block would get called IMMEDIATELY
> > after the catch block was completed.

> > Surprise Surprise there was a huge delay!!!! At least in my de{*filter*}.

> > Is this just an artifact of the de{*filter*}?

> > Any ideas would be greatly appreciated.



Sun, 17 Apr 2005 00:55:30 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. The if ~ else block in try~catch block

2. Catching Win32 exceptions with a C++ catch-block

3. exceptions thrown in a finally block

4. Returning from a try-finally block

5. Closing SqlDataReader in finally block;

6. (SEH) try-finally block and _endthreadex

7. blocking/non-blocking IO

8. Changing a blocking socket to a non blocking socket

9. Q. blocking/non-blocking calls in CSocket

10. Error C3204: _alloca cannot be called from within a catch block

11. Optimizer ignores try-catch block

12. try catch block

 

 
Powered by phpBB® Forum Software