tags:

views:

73

answers:

6

I'm implementing a TryParse(string s, Out object result) method. If the parse fails, I would like not to touch the out parameter so any previous result will remain intact. But VS2k8 won't let me. I have to set the value of the out object no matter what.

Should I just put result = result for the sake of pleasing the compiler? Am I missing something?

+2  A: 
result = null;
Eoin Campbell
Then I would dftly touch the parameter. That is basically the beef of my question.
borisCallens
+7  A: 

Assign null (or default(T) more generally). You must assign a value, that's what 'out' means.

Brian
Hmm, it seems to be the common understanding that indeed this would be so. I would like it more if I could have the option to set my variable to a fallback value, then do a tryparse and work with my variable that now either has a validly parsed value or the fallback value.
borisCallens
You could do that with a 'ref' parameter, but then you are departing from what has (for better or for worse) become the 'standard idiom'.
Brian
@boris - the fallback value of default(T) is safe. As a rule, the calling code shouldn't really even look at this value if they are given a `false`.
Marc Gravell
A: 

Just put some default value. For example the Int32.TryParse method puts zero.

1800 INFORMATION
Default value means default(T) to be exact, right?
Kirtan
For a generic type that would be correct
1800 INFORMATION
+6  A: 

Your suggestion of result = result won't work, because it's an out parameter - it's not definitely assigned to start with, so you can't read its value until you've assigned a value to it.

result = null;

is definitely the right way to go for an object out parameter. Basically use default(T) for whatever type T you've got. (The default operator is useful in generic methods - for non-generic code I'd normally just use null, 0, whatever.)

EDIT: Based on the comment from Boris, it may be worth elaborating on the difference between a ref parameter and an out parameter:

Out parameters

  • Don't have to be definitely assigned by the caller
  • Are treated as "not definitely assigned" at the start of the method (you can't read the value without assigning it first, just like a local variable)
  • Have to be definitely assigned (by the method) before the method terminates normally (i.e. before it returns; it can throw an exception without assigning a value to the parameter)

Ref parameters

  • Do have to be definitely assigned by the caller
  • Are treated as "definitely assigned" at the start of the method (so you can read the value without assigning it first)
  • Don't have to be assigned to within the method (i.e. you can leave the parameter with its original value)
Jon Skeet
So it is an accepted procedure to overwrite whatever value the out par had in the first place?
borisCallens
It's more than accepted: it's required. An out parameter *must* be definitely assigned before the method terminates normally (i.e. returns rather than throws)
Jon Skeet
It is impossible to do otherwise. This is what 'out' means - the client value will be (over)written. The advantage to 'out' over 'ref' is that the client need not bother initializing the variable, he can just declare it, assured that some 'initial' value will be set when passed in 'out' position.
Brian
I figured it would be worth editing the answer to clarify that :)
Jon Skeet
I wasn't aware of the out vs ref. Is there a commonly used form to use with a ref par like you have TryXx() for out?
borisCallens
A: 

You could throw an exception before the code that is supposed to set result.

Tal Pressman
A TryParse method is not really supposed to throw an exception in the case of an invalid parse. This would probably be looked on as a violation of the implicit contract
1800 INFORMATION
A: 

You could use ref instead of out if you don't want to assign a value, although this must then be initialised by the caller.

Lee