Why are 'out' parameters in .NET a bad idea?

Question

Why are \'out\' parameters in .NET a bad idea?

I was recently asked this, but I had no real answer besides it\'s simply unnecessarily complicating an application. Wh

Answer 1

Well , there is no clear answer for this,but simple use case for out parameter would be "Int.TryParse("1",out myInt)"

The XXX.TrayParse method job is, it converts a value of some type, to another type, it returns to you a boolean flag to indicate the conversion success or failure, which is one part the other part is the converted value, which is carried by the out parameter in that method.

This TryParse method was introduced in .NET 2.0 to get over the fact that XXX.Parse will through an exception if conversion fails and you have to put in try/catch around the statement.

So basically it depends on what your method is doing, and what method callers are expecting, if you are doing a method that returns some form of response codes , then out parameters could be use to carry out method returned results.

anyway Microsoft says "Avoid using out parameters" , in their design guideline , check this msdn page http://msdn.microsoft.com/en-us/library/ms182131(VS.80).aspx

Answer 2

I would say the answer you gave is about the best there is. You should always design away from out parameters if possible, because it usually makes the code needlessly complex.

But this is true of just about any pattern. If there is no need for it, don't use it.

Answer 3

I don't think there is a real reason although I haven't seen it used that often (other than P/Invoke calls).

Answer 4

It's not always a bad idea to use out parameters. Usually for the code that tries to create an object based on some form of input it's a good idea to provide a Try method with out parameters and boolean return value, not to force the method consumer to wrap try catch blocks all over, not to mention the better performance. Example:

bool TryGetSomeValue(out SomeValue value, [...]);

this is a case where out parameters are a good ideea.

Another case is where you want to avoid costly large structure passing between methods. For example:

void CreateNullProjectionMatrix(out Matrix matrix);

this version avoids costly struct copying.

But, unless out is needed for a specific reason, it should be avoided.

Answer 5

One point I don't see mentioned is that the out keyword also requires the caller to specify out. This is important since it helps to make sure that the caller understands that calling this function will modify his variables.

This is one reason why I never liked using references as out parameters in C++. The caller can easily call a method without knowing his parameter will be modified.

Answer 6

I'd say my reason to avoid it, would be because it is simplest to have a method process data and return one logical piece of data. If it needs to return more data it may be a candidate for further abstraction or formalization of the return value.

One exception is if the data returned is somewhat tertiary, like a nullable bool. It can be true/false or undefined. An out parameter can help solve a similar idea for other logical types.

Another one I use sometimes is when you need to get information through an interface that doesn't allow for the 'better' method. Like using .Net data access libraries and ORM for example. When you need to return the updated object graph (after an UPDATE) or new RDBMS-generated identifier (INSERT) plus how many rows were affected by the statement. SQL returns all of that in one statement, so multiple calls to a method won't work as your data layer, library, or ORM only calls one generic INSERT/UPDATE command and can't store values for later retrieval.

Ideal practices like never using dynamic parameter lists, or out parameters, aren't always practical all the time. Again, just think twice if an out parameter is the really right way to do it. If so, go for it. (But make sure to document it well!)