Exceptions to be Thrown by BlobStore Implementations

I recently got a question on what Exceptions a BlobStore implementation should throw and this blog post answers that question. BlobStore implementations should throw either BlobStoreException or other exceptions.

BlobStoreException is meant to be used for conditions that RBS client library expects and knows how to handle (either now or in the future). For this reason, there is a defined list of cases where BlobStoreException should be thrown. This is the list of values of the BlobStoreExceptionCode enum. If a condition falls in this list, then a BlobStoreException must be thrown. If a condition does not fall into this list, then a different exception must be thrown.

So the next question is: which exception should a BlobStore implementation throw? .NET Framework guidelines say that as far as possible, we should throw system exceptions. This helps with easier handling of the error, possibly by higher level applications or by admins. In the case of RBS, the client library wraps any non-BlobStoreException Exceptions in another exception (RemoteBlobStoreException with ExceptionCode = BlobStoreUnhandledException) and sets the InnerException to the original exception thrown by the BlobStore. So applications will need to catch and handle this new exception. If LogLevel is configured to Error or higher, the log will also contain details of the exception as well.

In general, it would be very rare to have a condition not covered by the list in BlobStoreExceptionCode. One example where it is not covered is present in the sample provider. The sample FileStoreLibrary throws non-BlobStoreExceptions such as ArgumentNullException. In this case, if this exception gets thrown, it indicates a bug in RBS client code, and it should not be hidden by a BlobStoreException.

If other components/dlls called by a blob store provider can throw exceptions such as OutOfMemoryException, the BlobStore implementation should be careful about letting it bubble up directly. Often times the correct thing to do is to throw a BlobStoreException with BlobStoreExceptionCode set to OperationFailedAuthoritative. Remember, the list of conditions indicated by BlobStoreExceptionCode are the ones that RBS client library knows how to handle, and it always takes precedence.

- Pradeep.

Comments

• Anonymous
  February 04, 2011
  Is there any exception a provider can use to "reject" a blob as EBS permitted? It makes sense to be able to decide that blobs should not be in the external store so given a provider has logic for this, how does it accomplish this?

• Anonymous
  February 04, 2011
  Hi Doug, No, there is no such exception in exception code for RBS. SharePoint has done a few things in the new version (2010) that removes the need for such an exception code. From Sean Watson in SharePoint: We added the reject policy for the following reasons which don’t apply in RBS.

1. Blobs smaller than a certain size don’t make sense to be stored in EBS. For RBS we natively support that policy (SPRemoteBlobStorageSettings.MinimumBlobStorageSize).
2. We tell the EBS provider the SPSite.ID; an EBS provider could be configured to force certain SPSites to be stored inline. For RBS, we don’t have a way to pass that information (since RBS isn’t SharePoint specific and in general there isn’t an equivalent notion in all RBS clients). You can accomplish that policy by isolating these SPSite in content databases without an active RBS provider (but this won’t work in EBS since the provider is registered at the SPFarm level).

• Anonymous
  February 04, 2011
  Thanks, Any chance, in SharePoint's implementation, storePoolId has any connection to any identifiable object in SharePoint? Given answer #2, I wonder does performance testing show RBS is at least neutral compared to in-SQL storage, since some SharePoint objects can be created after provisioning that really shouldn't be externalized?

• Anonymous
  February 04, 2011
  No, not directly. storePoolId belongs to a collection, and with SharePoint 2010 SP1, each collection stores only blobs associated with a single SP site collection. Performance of RBS will greatly depend on the blob store used. Testing with the RBS Filestream blob store shows a performance increase for slightly large files (e.g. large docs or powerpoint presentations) and a big performance boost if you are storing very large files (e.g. PowerPivot cubes or videos). As mentioned in the previous post, you can use SPRemoteBlobStorageSettings.MinimumBlobStorageSize to store only large blobs in RBS, thereby ensuring good performance.