Passing by reference twice

[Jon Skeet [C# MVP]]

I think a success/failure or status return is quite handy:

if ( DoSomething( a, b, ref out c, ref out d))
// we're golden

This was especially true before nullable values, where it may be hard to
determine from the out params whether the function even suceeded if results
are allowed to be null.
As most functional languages have an implcit notion of success/failure
(where failure sometimes results in backtracking if the language supports
it) even if programming c# in a functional style, I don't think returning
true/false is so bad.

That's okay *sometimes* - but only sometimes. Unless you think people
are likely to call the method a significant amount in a "failure" case
(as per Double.TryParse etc) I'd favour an exception instead. It's far
more informative than a return value, and is a lot harder to
accidentally ignore.

 

[Michael C]

This was especially true before nullable values, where it may be hard to
determine from the out params whether the function even suceeded if
results are allowed to be null.
As most functional languages have an implcit notion of success/failure
(where failure sometimes results in backtracking if the language supports
it) even if programming c# in a functional style, I don't think returning
true/false is so bad.

It is if it's in place of an exception. So often I see code like this:

bool SetSomeValueInSomeList(int index, object value)
{
if(index < 0 || index >= mylist.Count) return false;
mylist[index] = value;
return true;
}

Michael

 

[Michael C]

That's okay *sometimes* - but only sometimes. Unless you think people
are likely to call the method a significant amount in a "failure" case
(as per Double.TryParse etc) I'd favour an exception instead. It's far
more informative than a return value, and is a lot harder to
accidentally ignore.

Plus a lot more consistant.

Michael