CODEWITHSUNDEEP
c#.net
anderZubi
anderZubi

Reputation: 6424

void vs. object returning null

Since void signature is used to denote that a method does not return anything, such kind of methods, I write it the following way:

private void MyMethod()
{
    // Body of the method.
}

However, in many places I have seen methods that are not intended to return anything, written in following way:

private object MyMethod()
{
    // Body of the method

    return null;
}

From my point of view, both code pieces do the same. So, which can be the purpose of using this second one? Which is the difference between them? And is any of them preferred over the other?

Upvotes: 2

Views: 3115

Answers (8)

0lukasz0
0lukasz0

Reputation: 3267

Second is misleading. Someone who uses your class would expect to get something after executing this method. You should avoid writing such methods if they do not intend to return meaningful values under any circumstances.

Even if you overidding class which returns something meaningful you should consider using NullObject design pattern so that you do not broke existing APIs and follow LSP. Returning null creates redundancies with extra null checking logic and is counterintuitive.

Upvotes: 0

Ian
Ian

Reputation: 34489

The second one written as is, with a single return is generally useless, it'll slow down the performance slightly and makes the API harder to consume. There are however slight variations where it may be useful such as:

  • There are multiple return points, and this is the final one indicating a lack of an object. For example you might be returning an instance of an object normally, but for some reason you don't have one this time around. (Example 1)

  • If the method were marked differently, say public virtual then the default implementation or an overridden one may not return a value, but others might. (Example 2)

Example 1:

public object MyMethod()
{
   if(myObj != null)
      return myObj.Result();

   return null;
}

Example 2:

// Derived Class
protected override object MyMethod()
{
    // We don't need a result from here so we don't have an implementation of
    // anything, but the base implementation doesn't make sense. This however
    // could be breaking SOLID principles.
    return null;
}

// Base Class
protected virtual object MyMethod()
{
    return new MyObj();
}

Upvotes: 7

Johannes Wanzek
Johannes Wanzek

Reputation: 2875

The only good practice would be returning a bool value every time, to confirm if the method has received the call and arguments successfully OR if the method did successfully execute the logic inside.

Returning a NULL is useless and misleading...

Upvotes: 0

charan
charan

Reputation: 21

second method itself returning something in your case its null. i dont feel it as non value returning method. if method is not returning better to practice with void

Upvotes: 0

ojlovecd
ojlovecd

Reputation: 4892

For the second one, if there is no other return value in the method body, I would say it is useless. As long as you guarantee the method won't return any value, please use the first one.

Upvotes: 0

gasroot
gasroot

Reputation: 523

perhaps the second can be used to call an exception treatment

Upvotes: 1

mohkhan
mohkhan

Reputation: 12305

The second one is a bad practice. We are unnecessary telling the compiler to check for the return type. Maybe it is done for future changes.

Upvotes: 0

Bathsheba
Bathsheba

Reputation: 234665

With the second one, the caller can test for nullness which is a useful indication of success or failure, if for some reason, it's not desirable to throw an exception. With the first one no such facility is available.

Upvotes: 0

Related Questions