Stupid Question 90: Do I have to use the return value of a method?

I think that the question is more about why you aren't using the return value, rather than whether you're using it.

Let's say you're using a method from a library, but only for some side-effect the method has and you're ignoring the return value. The developer has some tests that verify the return value given specific input and decide for some reason to refactor the method and change or remove the side-effects it has. Their test still passes so they release a new version but when you start using it your code now has a bug as the side-effect you relied on no longer works. If you're lucky they developer documented the change but if the side-effect was internal to their library they may not have and you have your work cut out to figure out why your code broke. 

Hi Iris,

I would argue it's best to take advantage of return values of methods (or functions depending on the nomenclature of the language/framework being used) due to understanding the intent of code written.  

For example, consider the following C# methods (Page_Load being an ASP.NET page event setting Text properties of Literal Web Controls):

        protected void Page_Load(object sender, EventArgs e)
        {
            const string mikeIsAGeek = "true";
            bool isMikeAGeek = IsAGeekTryParse(mikeIsAGeek);
            litMikeIsAGeek.Text = isAGeek.ToString();

            bool isMikeAGeekAlternative = IsAGeekTryParseAlternative(mikeIsAGeek);
            litMikeIsAGeekAlternative.Text = isMikeAGeekAlternative.ToString();
        }

        public static bool IsAGeekTryParse(string isAGeekAsString)
        {
            bool isAGeek = false;
            bool.TryParse(isAGeekAsString, out isAGeek);
            return isAGeek;
        }

        public static bool IsAGeekTryParseAlternative(string isAGeekAsString)
        {   
            bool isAGeek = false;

            if (bool.TryParse(isAGeekAsString, out isAGeek))
             {
                return isAGeek;
              }

            return false;
        }

Both methods return the same value.

However, within the first boolean TryParse method -- the method named IsAGeekTryParse -- I have no idea if the value ascertained was due to it being a string of "true", "false", or something else completely -- perhaps a string that is not a boolean.

Within the second method, I have more information -- I can easily figure out whether it's due to the string being "true", "false", or something else.

It's all about readibility and clarity.  We developers should be considerate of the next developer that has to come along and support the code we've written.  

We have all been that poor developer that has to support someone else's code -- and many times poor code at that!.

Mike Reynolds 

As you said, no you don't have to but its quite permissible (and common) the API you are calling has already completed the operation you want and is simply returning an object you 'could' work with further, but surely don't have to.

You may call for example a CSLA method like customer.Save() which returns another object but it also has saved the state and you do nothing with the return object. It's there if you want to handle it, but nothing says you have to here, even for good practice. It's all up to the API and what you want to do with it ideally. 

Something as simple as MessageBox.ShowMessage will return a value, and if you want a fire and forget message you can just ignore it, same if you use a tryparse method then perform validation on  the outputted value, not the return value. There are cases where you can't avoid it 

There are some situations, such as adding a row to a DataTable, where you don't need the returned row index, so I feel it's fine to call myDataTable.Rows.Add(newRow) without using the return value.

However, when calling your own methods, if you write a method that provides a return value (say, WriteLogFile() that returns a Boolean for success) that you don't use, then it's a good clue to refactor the method.  The method may be doing two things, the first thing is something internally, and the second is providing a return value, and if you're calling it for only one of those two things, then it's time to split the method into two methods, one function and one sub.

Could you please update your post with the link to the SO thread you mentioned in the video? 

I'd say "in theory" you should use it, but in practice, it's often not necessary.  

The problem is in C# and other C derived language (as well many other programming languages), while there is a theoretical difference between a function (which should have no side effects, but returns a value) and a subroutine (which have side effects, but should not return a value), there is no practical difference --- every method can have both side effects and a return value.

Hence, if you are creating a subroutine,  you can also pass some information back to the caller "for free".  For example, in C, the printf() function returns a value (the number of characters printed), but virtually no one ever uses that value.   However, if you happen to need to know that value, it would be very difficult to determine any other way.

So, if we were to be purists, our subroutines would have side-effects, but no return values, and our functions would have return values but no side-effects and we'd always use the return value, because there would be no other reason to call the function.