SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What are the best practices for error handling in Asynchronous Event Receivers? I'm currently writing an ItemAdded Event Receiver. The Status and ErrorMessage properties only seem to be relevant for synchronous event receivers. Setting them as follows does not appear to do anything (such as log to ULS) for asynchronous event receivers:

properties.ErrorMessage = "An error occurred in the xyz event receiver"
properties.Status = SPEventReceiverStatus.CancelWithError;

My current approach is to log known errors to the ULS using the SPDiagnosticsService, as documented here. I am also wrapping a try/catch around all of the code in my Event Receiver's ItemAdded method to catch any unexpected exceptions and log them to the ULS as well.

Does this sound like a valid approach? Is there any reason I would want to rethrow the unexpected exceptions back to the SharePoint framework?

share|improve this question
up vote 2 down vote accepted

You can't cancel an Asynchronous task as it's running in a separate context form the HTTP session.

The only method you'll have is to write to ULS.

As for re-throwing Exceptions, don't (in my opinion). Just catch whatever is already thrown by the object model and log.

share|improve this answer
Thanks for confirming my suspicions! – SharePoint Wrangler Jan 18 '11 at 16:44

Most of my event handlers look like this

public void HandleIngEvent(SPItemEventProperties properties) {
    try {
        //do stuff
    } catch (Exception e) {
        //note: these shown to user in browser
        throw new Exception("CustomEventReceiver, HandleIngEvent(): Exception: [" + e.ToString() + "].");

public void HandleEdEvent(SPItemEventProperties properties) {
    try {
        this.EventFiringEnabled = false;
        //do stuff
    } catch (Exception e) {
        //note: these shown in windows event log
        throw new Exception("CustomEventReceiver, HandleEdEvent(): Exception: [" + e.ToString() + "].");
    } finally {
        this.EventFiringEnabled = true;

ING exceptions are automatically thrown to the browser and logged to ULS, the information that is displayed (stack trace) can be controlled by the web.config settings.

ED exceptions are automatically logged to ULS and show in windows event log, so no need for custom SPDiagnosticsService.

I tend to only use this

properties.ErrorMessage = "Start date is after end date"
properties.Status = SPEventReceiverStatus.CancelWithError;
properties.Cancel = true;

for reporting validation errors to the user based on the data they have entered.

share|improve this answer
Is it really necessary for you to throw another (new) Generic Type Exception, when the object model has (at some point) gone to the effort of throwing you a specifically Typed Exception with all the information relevant to the circumstances? I'd just have a throw; and carry the same Exception object Iincluding the callstack, InnerException, Message, etc. properties) further back up the callstack. – James Love Jan 17 '11 at 23:52
i find that it makes tracing the errors a little easier, but yeah you dont have to do that – djeeg Jan 18 '11 at 0:53
djeeg, thanks for your response. You're approach is valid, but I went with James' approach, so I marked his answer as correct. – SharePoint Wrangler Jan 18 '11 at 16:47

Your Answer


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.