How can I show that a method will never return null (Design by contract) in C#

Question

I have a method which never returns a null object. I want to make it clear so that users of my API don't have to write code like this:

if(Getxyz() != null)
{
  // do stuff
}

How can I show this intent?

Symbolize

Besides, there's no way to know if you could even return a non-null object in the first place (unless it's a struct) Maybe you want to return a struct? – Penknife

Now standardized as Contract.Ensures(Contract.Result<T>() != null) in Code Contracts - postconditions in System.Diagnostics.Contracts namespace. From the first link above, I get this link to download. – Undercarriage

Answer 1

Unfortunately there is no way built in to C#

You can document this fact, but this won't be automatically checked.

If you are using resharper, then it can be set up to check this properly when the method is marked with a [NotNull] attribute.

Otherwise you can use the Microsoft Contracts library and add something similar to the following to your method, but this is quite a lot of extra verbiage for such a simple annotation.

Contract.Ensures(Contract.Result<string>() != null)

Spec# solved this problem by allowing a ! after the type to mark it as a non-null type, eg

string! foo

but Spec# can only be used to target .NET2, and has been usurped by the Code Contracts library.

Colligate

Uh, but this is wrong...you can guarantee that a method does not return null. See any of the other answers... – Mckinleymckinney

Using a struct does not help if you want to return a non-null string. You could return a not-null struct containing a string that may be null, but how is that any better? – Colligate

the syntax is wrong on your Contracts example. The Result should be a method call: Contract.Result<string>() – Flosi

Now standardized as Contract.Ensures(Contract.Result<T>() != null) in Code Contracts - postconditions in System.Diagnostics.Contracts namespace. – Undercarriage

Answer 2

Unless you are using a type based on System.ValueType, I think you are out of luck. Its probably best to document this clearly in the XML/metadata comment for the function.

Siqueiros

Answer 3

I don't know that there is a best practice for doing so from an API as I would still program defensively and check for null as the consumer. I think that this is still the best practice in this case as I tend to not want to trust other code to always do the right thing.

Consubstantial

Answer 4

The only type-checked way to ensure that a C# object never returns null is to use a struct. Structs can have members that contain null values, but can never be null themselves.

All other C# objects can be null.

Example code:

public struct StructExample
{
    public string Val;
}

public class MyClass
{
    private StructExamle example;

    public MyClass()
    {
        example = null; // will give you a 'Cannot convert to null error
    }

    public StructExample GetXyz()
    {
        return null; // also gives the same error
    }
}

The above example will not compile. If using a struct is acceptable (it becomes a value type, gets passed around on the stack, can't be subclassed) then this might work for you.

Mckinleymckinney

Note that structs pass by value by default, while classes pass by ref by default. The difference is that the contents of the struct is dumped onto the stack when passing, while for classes only a reference is dropped on the stack, allowing you to interact with the original object rather than a new copy. This can be overridden by using the "ref" keyword, but then you 1) have to remember to use it every place that you don't want a copy, and 2) it can be null again, which was what you were trying to avoid in the first place. – Quianaquibble

Answer 5

I like to think of it the other way around: if my function could return a null value I better make sure that the function's user knows about it.

Tanyatanzania

Answer 6

If your users have your source code using a standard design by contract API like: http://www.codeproject.com/KB/cs/designbycontract.aspx can make things clear.

Otherwise your best bet is through documentation.

Digitalis

Answer 7

Either document it well (maybe with .NET standard documentation system) or you have to use some Contract API. Here are some: Link http://www.codeproject.com/KB/cs/designbycontract.aspx

Falchion

Answer 8

You could include a Debug.Assert() method. While this certainly won't enforce the condition, it should make it clear (along with documentation) that a null value isn't acceptable.

Yeryerevan

Answer 9

Document it and provide the source code.

Compunction