Catch exception in web part, or let it bubble up?

Question

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?

Answer 1

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.

Answer 2

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 }

Answer 3

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.

Answer 4

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