Microsoft Webservices - Ok to not catch webservice exceptions?

Author

Ok to not catch webservice exceptions?

Tim Johnson

2005-03-11, 9:00 pm

I'd been catching exceptions in my webservice and logging them, but it
occurs to me a better strategy would be to catch them, log them, and
re-throw them. That way the caller can do his own try/catch and display the
actual exception object and messages from the web service. Or if you don't
really care about logging exceptions, just don't bother catching them in the
webservice, just let them propagate to the caller!

Here's my question. If I don't catch an exception in a desktop app it
crashes. But in my webservice app it seems to go along just fine. I'm
assuming this is because it's not really an app but a call to the webservice
dll from some ASP session. Not being an ASP guy I don't really know how
this works.

So is it really ok to simply not catch exceptions in a webservice so the
caller can catch them? Or is it better to catch and rethrow them if you
want the caller to see them too?

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625

Kevin Spencer

2005-03-11, 9:00 pm

Good question, Tim. I suppose it all really depends on the requirements. But
as a general rule, I would throw the exceptin and let the client handle it
however it wants to. If you want to log exceptions on the server, that's
fine too.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You S

Is What You Get.

"Tim Johnson" <tjohnson@high-point.com> wrote in message
news:OpH2ejnJFHA.3132@TK2MSFTNGP12.phx.gbl...
> I'd been catching exceptions in my webservice and logging them, but it
> occurs to me a better strategy would be to catch them, log them, and
> re-throw them. That way the caller can do his own try/catch and display
> the actual exception object and messages from the web service. Or if you
> don't really care about logging exceptions, just don't bother catching
> them in the webservice, just let them propagate to the caller!
>
> Here's my question. If I don't catch an exception in a desktop app it
> crashes. But in my webservice app it seems to go along just fine. I'm
> assuming this is because it's not really an app but a call to the
> webservice dll from some ASP session. Not being an ASP guy I don't really
> know how this works.
>
> So is it really ok to simply not catch exceptions in a webservice so the
> caller can catch them? Or is it better to catch and rethrow them if you
> want the caller to see them too?
>
> --
>
> Tim Johnson
> High Point Software, Inc.
> www.high-point.com
> (503) 312-8625
>
>
>

Tim Johnson

2005-03-11, 9:00 pm

My specific question though is, is it ok to just not catch the exception and
let it pass thru to the caller (which appears to work just fine), or will
that be bad for the ASP session and/or webservice? In other words, why
catch at all if you're just going to re-throw?

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625

"Kevin Spencer" <kevin@DIESPAMMERSDIEtakempis.com> wrote in message
news:%23rl%23jwnJFHA.3788@tk2msftngp13.phx.gbl...
> Good question, Tim. I suppose it all really depends on the requirements.
> But as a general rule, I would throw the exceptin and let the client
> handle it however it wants to. If you want to log exceptions on the
> server, that's fine too.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> What You S

Is What You Get.
>
> "Tim Johnson" <tjohnson@high-point.com> wrote in message
> news:OpH2ejnJFHA.3132@TK2MSFTNGP12.phx.gbl...
>
>

Kevin Spencer

2005-03-11, 9:00 pm

It certainly is not going to cause any trouble if you catch and rethrow it.
This technique is often used to log exceptions.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You S

Is What You Get.

"Tim Johnson" <tjohnson@high-point.com> wrote in message
news:e9p%23o5nJFHA.2396@TK2MSFTNGP12.phx.gbl...
> My specific question though is, is it ok to just not catch the exception
> and let it pass thru to the caller (which appears to work just fine), or
> will that be bad for the ASP session and/or webservice? In other words,
> why catch at all if you're just going to re-throw?
>
> --
>
> Tim Johnson
> High Point Software, Inc.
> www.high-point.com
> (503) 312-8625
>
>
> "Kevin Spencer" <kevin@DIESPAMMERSDIEtakempis.com> wrote in message
> news:%23rl%23jwnJFHA.3788@tk2msftngp13.phx.gbl...
>
>

Luca Bonifazi

2005-05-10, 8:59 am

Il Fri, 11 Mar 2005 12:28:17 -0800, Tim Johnson ha scritto:

> I'd been catching exceptions in my webservice and logging them, but it
> occurs to me a better strategy would be to catch them, log them, and
> re-throw them. That way the caller can do his own try/catch and display the
> actual exception object and messages from the web service. Or if you don't
> really care about logging exceptions, just don't bother catching them in the
> webservice, just let them propagate to the caller!
>
> Here's my question. If I don't catch an exception in a desktop app it
> crashes. But in my webservice app it seems to go along just fine. I'm
> assuming this is because it's not really an app but a call to the webservice
> dll from some ASP session. Not being an ASP guy I don't really know how
> this works.
>
> So is it really ok to simply not catch exceptions in a webservice so the
> caller can catch them? Or is it better to catch and rethrow them if you
> want the caller to see them too?

Hi tim,
i personally use a mixed sistem:
For exception throwing i use a custom exception throw.
In a custom exception you can fill the message with "service centric" info,
not with ,perhaps security dangerous sql error informations.

The web service can be used with different client architectures and error
information hiding is the best technique.

If you have your client developped with dotnet custom exceptions can be the
way.For other soap clients implementation too, the message contain "your"
error description.

If the service is open to word exception logging can be the best way.

Sorry for my english
Regards
Luca

Sponsored Links