Every developer will, at some point, need to check if a generic SObject is a type of another concrete SObject type.

Before I get started I’d like to give a shout out to Salesforce Girl, who’s blog inspired this.

A common place where this is used is the owner of a custom object or the who.id and what.id of objects that contain polymorphic keys like Task. One would be inclined to use the Apex instanceof keyword to perform this test. The problem with this is instanceof only compares a concrete object to a class.. This won’t work when comparing a generic SObject to something else.

Let’s look at an example using a custom object I’ve created called Project:

We want to check if the Project’s owner is a User or Group prior to performing further operations on the result. How can we accomplish this? Here’s one way:

On line three we are attempting to create a new Group object using the ownerId. If the ownerId is an invalid group id, an exception will be thrown. We’re handling this in the catch block and since the only alternative is that ownerId is a valid id for a user we’re compensating in the exception and creating a new User object in line 6.

We can easily verify this with:

This works where our options are binary, as in this example, but it’s not optimal and it doesn’t offer much for reusability. What if we also wanted to check the whoId of any related tasks of our project? Our code could get very messy in a hurry. Extra credit if you’ve asked what happens if line 6 throws an exception.

By the way, If you try this using instanceof you would get an error mentioning incompatible types and apocalyptic prophecies.

So how do we make this better? Well, one way is to make the comparison more reusable. Another is to make it more generic to handle broader use cases. Let’s create a new class that we can call to handle the comparison for us.

Here we pass in arguments for the SObject we want to compare and the type we want to compare against. In line four we get the SObjectType information for the object we want to compare to. Line five is pretty self-explanatory. Line seven we compare the SObject type against the type we are comparing to and return true if they are the same. We return false if there were no exceptions and the types are not the same. Now we can use our new class with the same problem.

You can grab the Gist for this to play with more.

In this post I focused on a single custom object but you could use this same approach any time you want to compare a generic SObject to another type. I’ve proposed one way to do this. Can you think of a better one? If so please comment.

Follow me on Twitter @ryanjupton