C# how to handle GUID return type exception?

I have a method with the following signature:

public Guid FindTermIDFromCu开发者_StackOverflow中文版stomProperty() 
{
     // Logic here to find an item and return the guid 
}

My problem is, if no item was found in the function then there will be no GUID to return - this goes without saying! But is there a way to return some bland GUID?

Better yet, is there a more generic approach I could take, not only for GUIDs, but generally when I'm returning a strong type? I don't really want to use an object as return type, there must be a better way.

Thanks in advance.

To answer your first question, you could use Guid.Empty, which returns a guid guaranteed to be all zeroes.

As for your second question, one approach is to return a bool and use an out param as an argument, with the bool indicating if you got a value or not. Not everyone likes working with out parameters though.

public bool FindTermIDFromCustomProperty(out Guid termId) 

You could return a nullable Guid so if no item was found you would return null

public System.Nullable<Guid> FindTermIDFromCustomProperty() 
{
     // Logic here to find an item and return the guid

     if (!found)
     {
         return null;
     }
}

Nullable types work for structs.

Reference types can already be set to null.

If you're using .NET 2.0 or later, you can return a nullable type.

public Guid? FindTermIDFromCustomProperty() 
{
    // Logic here to find an item and return the guid 
    else
        return null;
}

var guid = FindTermIDFromCustomProperty();
if (guid.HasValue) // or "if (guid != null)"
    DoSomethingWith(guid.Value);

So you have two options on what to return

Option 1: For value types: int, datetime etc. you can return the default value, (0, DateTime.minValue, Guid.Empty), or use a nullable, Guid?, int? etc. which can return null. Although the nullable is great for this, people tend to shy away from it for some reason or another, so using this sometimes depends on the group your working with. I know teams that just don't use them. They think their awkward and shy away, and in this case suddenly adding them in makes it stick out in the rest of the code, because it doesn't follow the psuedo-standards of the rest of the application. Personally, I like nullables, but not everyone feels the same way I do.

For reference types you can just return null.
Returning null for collections: There is another debate on dealing with collections as what you should return. You can return null if the collection doesn't have anything in it, or you can return an empty list etc. You can split hairs that they mean different things, but once again, you should follow what the rest of the program does. What you have to remember is that a lot of people forget that in things like a foreach statement the collection variable calls GetEnumerator(), and that will throw an exception if the collection object is null.

Option 2: When you don't find an object you are looking for you throw an exception stating you didn't find what you were looking for.

There is a hot debate as to which to use, on one hand returning the default value won't directly alert the calling method that something isn't found, it has to know that the return value isn't actually an id (sometimes this is less obvious than you'd think). On the other, throw an exception means that the calling method has to know to expect an exception could be raised. Really depending on your situation determines which is the correct answer.

You could return Guid.Empty. Or throw an exception (either one of the built-in ones or something custom like ItemNotFoundException). Or declare your method with a Nullable type in the return and return null:

public Nullable<Guid> FindTermIDFromCustomProperty() 
{
     // Logic here to find an item and return the guid 
}

Try using nullable types. For value types you can make them nullable by adding a ?, e.g.

int? x = null;

if ( x != null ) {

}