I'm writing a web part for other sites to use in their SharePoint installation. In the logic of the web part I throw exceptions at certain failure points. I'm wondering whether it is a better practice to catch the exceptions and deal with them myself, or let them bubble up so the developers/administrators making use of this web part can deal with them at the page level?

If I catch them myself I guess this quarantines the web part from causing the whole page to fail if it throws an exception. However, if I deal with the exception myself, it doesn't allow the 3rd party sites to deal with the exceptions in different ways, which they might want to.

This Exception Management in SharePoint page says:

...an unhandled exception in a single Web Part can prevent the Web page as a whole from being displayed. This behavior is sometimes desired because an unhandled exception can potentially corrupt data on the page. In other situations, it can be better to catch unhandled exceptions within Web Parts.

However I'm not really clear on which situations I might want to catch the exceptions myself, and in which I should let them propagate up -- any ideas and notes from the field?

4 Answers 4


If you handle the Exceptions you need to

  • Log the exception
  • Show a user friendly error message
  • Make sure not to expose any sensitive data
  • Release resources and leave application in a consistent way
  • Only catch exceptions you can handle

If you can't follow these principles let SharePoint handle the error. SharePoint does by default show an "Unknown Error" message - not good for the end users, but its a reason behind that and that is not to show any details that may be sensitive.

Assume that you handle an out of memory or corrupt files or whatever and you do not show that for the user or let SP handle it. If this is not logged or handled by SP then your admins might never find out why things went wrong. Esp if they are using monitoring tools (think SCOM) that checks the ULS logs for errors.


First of all you should code defensively, so you minimize the risk of throwing exceptions. One way of doing this is to always check your parameters in public methods before you use them (for example null check). In other words your exception handling shouldnt be a way to control the flow of your code logic, it should be a last resort. Catching and rethrowing in general is expensive and should be avoided. Eg. lots of methods have TryParse methods that should be preferred over Parse. In general you should understand the classes you work with and make sure you know what exceptions they throw.

When handling exceptions:

  • Log your exceptions. Patterns & Practices got a nice logging module that uses Service Locator pattern.
  • Catch as specific exceptions as possible in your private methods, and only if it makes sense. Catch all exceptions in your overridden public methods so that only the web part fails and not the whole page.
  • If you rethrow, dont define your exception as this will cast it as the caught exception

    catch ( Exception ex) { rethrow (e); // will cast exception as Exception }

    catch { rethrow; // will not cast exception }

  • Just have to say that the logging features in P&P is awesome - as the rest of that package! Commented Jun 15, 2010 at 14:31

This is my personal opinion, but Exceptions should NEVER EVER bubble up for end users to see.

Not only won't they know what to do with this information, they also won't be able to judge what the solution should be unless they are highly technical.

In the end you know your solution (web part) best, so catch whatever detail you can catch in the UI layer and display something remotely useful, even if it is just the telephone number for the helpdesk.

  • By 'user' I guess I mean a user of my web part, a client with their own SharePoint farm, who will be installing this web part in a page where they may be able to have their own exception handler at the page level. Not user as in end-user, i.e. not just a person logging in to SharePoint and using it. I'll edit the question, as it's not very clear! Anyway thanks point taken, better to handle the exceptions yourself.
    – ngm
    Commented Jun 15, 2010 at 9:47
  • I appreciate that there is a different between end-users and admin-users, but I don't think you can guarantee that there will only be configuration errors during the lifetime of the web parts. For additional SharePoint Development guidelines have a look at this free guide: blog.muhimbi.com/2009/05/muhimbis-sharepoint-development.html Commented Jun 15, 2010 at 10:00
  • Excellent, thanks for the link, looks great. Lots of hard earned SharePoint guidelines that will be most useful as a new developer.
    – ngm
    Commented Jun 15, 2010 at 10:22

Follow the simple principle of "catch what you can handle". If you cannot do anything meaningful after catching the exception then there is no point in doing so, unless your are rethrowing after logging or doing some processing.

Since you are distributing a webpart, which will be used by other sites/application, your webpart should behave gracefully as its residing in some other application which it doesn't owns.

So, the thing would be catch the exception, log it and display a friendly message in the webpart itself, rather than causing the entire site to be down, unless that is if you wanted (as there are certain requirements which warrants that).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.