Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers 4

up vote 4 down vote accepted

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.

share|improve this answer
add comment

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 }

share|improve this answer
    
Just have to say that the logging features in P&P is awesome - as the rest of that package! –  Wictor Wilen MCA MCM MVP Jun 15 '10 at 14:31
add comment

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.

share|improve this answer
    
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 Jun 15 '10 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 –  Muhimbi Jun 15 '10 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 Jun 15 '10 at 10:22
add comment

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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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