Soap call not protected with a try..catch?

[Greg Merideth]

This little bugger of a problem took us most of the day to track down
but I'm glad it happened as I would like to know why the WSDL generated
code that operates inside of a try..catch block throws an exception to
the screen when it craps out instead of being caught by the try..catch
block.

Basically, from inside of VS 2003 I added the reference to the web
service using a shared .dll to pass a class reference between the
client/server. Someone along the way changed the XmlRoot element name
of the clients soap class and this was causing the soap call to fail
with a "instance of an object not recognized..." error.

That I dont mind, fine, someone (we know who) changed the name but what
gets me is I added a set of try...catch blocks not only in my code
segment where I call the soap process but *also* in the WSDL code yet
the app was dumping to the desktop with a .net exception.

How would the soap call jump out of the try..catch block that it's in to
drop to the desktop with an exception error?

eg.

somecode()
{
soap call = new soap();
try { call.mycall(); } catch { whatever(); }
}

wsdl code

Around the web service method's generated call(), begincall() and
endcall() I have try{}..catch{} blocks.

The only thing I can think is the catch{}, in the wsdl code is empty but
still, why drop out of the app because of that?

[Chris Rolon]

Not sure what is happening with your request. To be sure, I wrote a simple
Web Service that that just throws an exception. In the client app I wrote:
try
{
localhost.Service1 s = new localhost.Service1();
s.HelloWorld();
}
catch
{
Console.WriteLine("Hello from exception");
}

The exception was caught as expected. I then changed the name of the Web
service method. Again the exception was caught.

Emtpy or not, the exception was caught.

--

Chris Rolon

"Greg Merideth" <be*****@forwardtechnology.net> wrote in message
news:uK********************@comcast.com...

This little bugger of a problem took us most of the day to track down
but I'm glad it happened as I would like to know why the WSDL generated
code that operates inside of a try..catch block throws an exception to
the screen when it craps out instead of being caught by the try..catch
block.

Basically, from inside of VS 2003 I added the reference to the web
service using a shared .dll to pass a class reference between the
client/server. Someone along the way changed the XmlRoot element name
of the clients soap class and this was causing the soap call to fail
with a "instance of an object not recognized..." error.

That I dont mind, fine, someone (we know who) changed the name but what
gets me is I added a set of try...catch blocks not only in my code
segment where I call the soap process but *also* in the WSDL code yet
the app was dumping to the desktop with a .net exception.

How would the soap call jump out of the try..catch block that it's in to
drop to the desktop with an exception error?

eg.

somecode()
{
soap call = new soap();
try { call.mycall(); } catch { whatever(); }
}

wsdl code

Around the web service method's generated call(), begincall() and
endcall() I have try{}..catch{} blocks.

The only thing I can think is the catch{}, in the wsdl code is empty but
still, why drop out of the app because of that?

[Greg Merideth]

Yeap there's something sinister going on here. I've disected the code a
few ways with the same result. I'll see if I can get an example whipped
up to post.

Chris Rolon wrote:

Not sure what is happening with your request. To be sure, I wrote a simple
Web Service that that just throws an exception. In the client app I wrote:
try
{
localhost.Service1 s = new localhost.Service1();
s.HelloWorld();
}
catch
{
Console.WriteLine("Hello from exception");
}

The exception was caught as expected. I then changed the name of the Web
service method. Again the exception was caught.

Emtpy or not, the exception was caught.