I would not be comfortable with a blanket statement like that. It is
entirely dependent upon your architecture. What you generally want to do
is catch specific exceptions when you need to take specific action based
upon that exception. At the end of your try...catch block, you can catch a
For what it's worth, it's also a very good idea to implement an event for
the UnhandledException. You can do this in your Application_Start so that
anytime an exception is thrown that you didn't handle, it can be handled by
your UnhandledException handler.
Jim Cheshire, MCSE, MCSD [MSFT]
This post is provided as-is with no warranties and confers no rights.
--------------------cpmsftngxa07.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTN GP08.phx.gbl!TK2MSFTNGP11.>From: "Roger Down" <roger.downc2i.net>
>Subject: What exception should I catch ??
>Date: Thu, 8 Jan 2004 14:14:30 +0100
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
>Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>NNTP-Posting-Host: oslo-bm1-r.consorte.com 18.104.22.168
phx.gblmicrosoft.public.dotnet.framework.aspnet.webservic es:21131>Xref: cpmsftngxa07.phx.gbl>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>I've read somewhere that it's not a good idea (or design) to catch all
>exception in one (big) catch(Exception e)... but instead catch the
>respective exceptions thrown by the respective classes used in a try
>When working with webservices, what soap related exceptions should I catch
>?? Is it enough to only catch a SoapException, or is there other important
>exceptions which I need to catch... so be safe... like network timeout,
>formatting error... I guess there are several layers in work when
>generating, sending and receiving a soap message/response...
>best of regards... :-)