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?

2 Answers 2


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.


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.

  • 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, 2011 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, 2011 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. Jan 18, 2011 at 16:47

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.