C# – Purpose of the ‘out’ Keyword at the Caller

An out parameter is very much like having an extra return value.

It's rarely a good idea to have an out parameter in a method which has a void return type, like the example you gave... but sometimes you want to be able to return multiple values at a time. Even in your example, you might want to encapsulate the "I'm reading from the console twice" idea in a single method call. It's somewhat unlikely in this case, because the operations are so easily separable - but in other cases, performing some work naturally gives two bits of information, and you don't want to have to repeat the work to get both bits. You could encapsulate them in a new struct or class, of course, but sometimes that's just a pain.

With .NET 4, it would often be a better idea to return a Tuple<...> instead, mind you. So whereas int.TryParse has a signature of

bool TryParse(string text, out int value)

it might have been better as

Tuple<bool, int> TryParse(string text)

Basically if you need to return more than one value, it's an alternative to using something like Tuple<,> or a custom type to encapsulate the values. The canonical example is probably int.TryParse and related methods. They want to convey two pieces of information back:

• The parsed value
• Whether or not parsing succeeded.

Now these could actually have been written using a return type of int? etc in this case, but it's the same principle for other cases. (For example, Dictionary<,>.TryGetValue, where the value stored in the dictionary may legitimately be null.)

I wouldn't say I despise out and ref parameters, but I do believe they should only be used occasionally, and only when there isn't a better alternative. Most of the uses of ref I see on Stack Overflow are due to a misunderstanding of parameter passing.