Is it OK not to handle returned value of a C# method? What is good practice in this example?

Out of curiosity...what happens when we call a method that returns some value but we don't handle/use it? And we also expect that sometimes this returned value could be really big. Where that value goes? Is it even created? If it is, are there any performance issues or other problems that can occur? (what is the best practice in this kind of situation?)

Let's say we have method that does some database operations (insert, update) and returns some data in DataTable object. And I also know that this DataTable object could be really big sometimes:

public static Datatable InsertIntoDB(...) 
{
      // executing db command, getting values, creating & returning Datatable object...
      ...
      return myDataTable;
}

And then when this method is used it is called like these:

DataTable myDataTable = InsertIntoDB(...);
// this Datatable object is handled in some way

But sometimes simply like this:

InsertIntoDB(...);
// returned value not handled; Problem???

On my first thought it think the system is smart enough to see the returned value is ignored and does not cause any problems (it is simply released) but I want to be sure and hear more detailed explanation of it from someone who is more experienced in this area than me.

Solution 1:

The returned value (or reference, if it's a reference type) is pushed onto the stack and then popped off again.

No biggy.

If the return value isn't relevant, you can safely do this.

But be sure that it isn't relevant, just in case.

Here's some code:

    static string GetSomething()
    {
        return "Hello";
    }

    static void Method1()
    {
        string result = GetSomething();
    }

    static void Method2()
    {
        GetSomething();
    }

If we look at the IL:

Method1:

.locals init ([0] string result)
IL_0000:  nop
IL_0001:  call       string ConsoleApplication3.Program::GetSomething()
IL_0006:  stloc.0
IL_0007:  ret

Method2:

IL_0000:  nop
IL_0001:  call       string ConsoleApplication3.Program::GetSomething()
IL_0006:  pop
IL_0007:  ret

Exactly the same number of instructions. In Method1, the value is stored in the local string result (stloc.0), which is deleted when it goes out of scope. In Method2, the pop operation simply removes it from the stack.

In your case of returning something 'really big', that data has already been created and the method returns a reference to it; not the data itself. In Method1(), the reference is assigned to the local variable and the garbage collector will tidy it up after the variable has gone out of scope (the end of the method in this case). In Method2(), the garbage collector can get to work, any time after the reference has been popped from the stack.

By ignoring the return value, if it really isn't needed, the garbage collector can potentially get to work sooner and release any memory that's been assigned. But there's very little in it (certainly in this case), but with a long running method, hanging onto that data could be an issue.

But far-and-away the most important thing is to be sure that the return value that you're ignoring isn't something that you should be acting on.

Solution 2:

EDIT: Softened the language very slightly, and clarified.

It's rarely a good idea to ignore the return value, in my experience - at least in cases where the return values are there to convey new information instead of simply being for convenience.

One example where I've seen it be okay:

int foo;
int.TryParse(someText, out foo);

// Keep going

Here foo will be 0 if either someText contained "0", or it couldn't be parsed. We may not care which was the case in which case the return value of the method is irrelevant to us.

Another example is in a dictionary - suppose you're trying to count the number of occurrences of each string. You can use:

int count;
dictionary.TryGetValue(word, out count);
dictionary[word] = count + 1;

If the word wasn't in the dictionary to start with, that's equivalent to there being a count of 0 - which is what will already happen as a result of calling TryGetValue.

As a counter-example, ignoring the value returned by Stream.Read (and assuming that it's managed to read all the data you asked for) is a common mistake.

If you don't need the return value and it will have taken a lot of effort to compute, it may be worth looking for something which will achieve the same desired side-effects without the extra computation - but there's no extra performance implication. I'd be more worried about the correctness of ignoring a return value than the performance.

EDIT: Other examples where it's okay to ignore the return value:

• Some fluent interfaces, including StringBuilder; while StringBuilder.Append(x).Append(y); uses the first return value for the second call, very often the return value of a call will be ignored, e.g. when appending in a loop
• Some collection calls can give return values which are sometimes ignored - e.g. HashSet<T>.Add which indicates whether the value was actually added, or was already present. Sometimes you just don't care.

But for the vast majority of the time, ignoring the return value of a method indicates that it's doing more than you need it to.