Last Friday, we’ve released drop 8 of our Guidance.
The main theme in drop 8 was exception handling in SharePoint. But we also did a bunch of refactoring in the application:
We looked at a bunch of exception handling scenario’s and how they relate to SharePoint.
The general guidance around exception handling still applies to programming in SharePoint. For example:
But please do read the general guidance with regards to exception handling. It’s a good read :)
It’s common to have different exception handling strategies for different places in your application. For example, in your web services, you’ll typically apply exception shielding, where you would log the original exception and replace it with a generic error message. An other example would be in your UI, where you would want to log the exception and display a message to a user.
We looked at a couple of these strategies for exceptionhandling in SharePoint where we can apply additional guidance or help. We’ve looked at exception handling in:
The default behavior of an unhandled exception in a web part is that the exception will bubble up to the page. There asp.net will redirect to an error page. Since SharePoint allows you to dynamically create pages and add some webparts to them, you might not want a single webpart to take down the whole page. So we’ve built something to allow you to do just that.
We typically apply the Model – View – Presenter pattern to webpart development, because that allows us to easily unit test our UI logic. This pattern looks like this:
The webpart loads up a view (an UserControl, to allow for the design time experience). The View loads up a presenter that holds all the UI logic and only communicates to the presenter using a interface (so we can mock out the view during while testing).
So how would we create an exceptionhandler for the webparts that can show error messages? The easiest approach is to allow the view to render error messages:
So our Presenter uses an ExceptionHandler to log and show exception messages. However, the (generic) Exceptionhandler needs some mechanism to display error messages. In this case, our view is the only thing our presenter knows. So we gave the view a special interface, the IErrorVisualizer interface, that the ExceptionHandler can use to display the correct error mesage.
You might not want to make the view responsible for showing 'fatal’ error messages. For one reason, makes the view more complicated. Another reason might be, that you would want a consistent way of displaying error messages across all your webparts. In that case, the following pattern might be better:
In this case, we’ve created an error visualizer. It’s just a control that knows how to display error messages. It implements the IErrorVisualizer interface. This way, the view is blissfully unaware on how errors are being displayed.
Now, if the presenter wants to call the error message, it not only needs a reference to the IMyView, but also to the IErrorVisualizer.
This is what the code from the presenter looks like:
1: public void LoadProduct(string sku)
5: logger.LogDiagnostic("In OnViewLoaded.");
7: Product product = productCatalogRepository.GetProductBySku(sku);
9: if (product == null || product.Sku == null)
11: // Show an error message to the user
12: new ViewExceptionHandler().ShowFunctionalErrorMessage("Could not find product information.", this.ErrorVisualizer);
16: this.view.Product = product;
20: catch(Exception ex)
22: // If something goes wrong, make sure the error gets logged
23: // and a non technical message is displayed to the user
24: new ViewExceptionHandler().HandleViewException(ex, this.ErrorVisualizer,
25: "Due to a technical problem, the product details cannot be displayed.");
All the code from the presenter is now in a try catch block. In the catch, we call the ViewExceptionHandler to handle the error. In this case, handling the error means: Log the error and show a ‘friendly’ error message.
Another ExceptionHandling strategy we’ve created is the ListExceptionhandler strategy.
If an unhandled exception occurs in a list, you should take the following actions:
So we’ve built a ListItemExceptionhandler that will do that for you.
As always, we hope you like the stuff we’re showing. If you have any feedback, comments or questions, feel free to ask me or the team (through the codeplex forums).