How well do you know your TryParse()?

[Luc Pattyn]

Hmm. That isn't very safe, result could contain an unintended value:

decimal val;
// now first use of val, not meant to provide the default value
val=some_garbage;
someOperations(val);
// now second use, forgetting to set the actual default value
bool OK=SafeTryParse("foo", ref val);
// val still contains garbage

One shouldn't give two roles to a single variable, so I'd rather have two overloads both using the out keyword:

// result is zero when parse fails
private bool SafeTryParse(string s, out decimal result);

// result is dflt when parse fails
private bool SafeTryParse(string s, out decimal result, decimal dflt);

You can still get the "overwrite when parse succeeds" effect by passing val twice to the latter. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

[Ravi Bhavnani]

I would argue that forgetting to set a valid initial value is programmer error, however I now like the idea of an explicit default.  That's what I initially implemented (link[^]), but like Alan, switched to the 2 parameter ref version.  I'm going to switch back. Thanks, /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[PIEBALDconsult]

Well it's zero, right?

[Lost User]

Do we actually care, if the value isn't being used?

string badNumericString = "Bogus";
Decimal foo; // will be initialized to 0 by the runtime
if (!Decimal.TryParse (badNumericString, out foo)) foo = 1; // default value here

..and if the TryParse don't use the value, it'll probably initialize it with the same value it initializes an empty variable. Since the variable hasn't been set (according to application logic), we can't be sure about the value unless we explicitly set it. (Future versions of .NET might display other behavior)

Bastard Programmer from Hell :suss:

[DaveyM69]

Eddy Vluggen wrote:

it'll probably initialize it with the same value it initializes an empty variable

Double checked using Reflector...

public static bool TryParse(string s, out decimal result)
{
return Number.TryParseDecimal(s, NumberStyles.Number, NumberFormatInfo.CurrentInfo, out result);
}

internal static unsafe bool TryParseDecimal(string value, NumberStyles options, NumberFormatInfo numfmt, out decimal result)
{
byte* stackBuffer = stackalloc byte[0x72];
NumberBuffer number = new NumberBuffer(stackBuffer);
result = 0M; // result is set to zero here!
if (!TryStringToNumber(value, options, ref number, numfmt, true))
{
return false;
}
if (!NumberBufferToDecimal(number.PackForNative(), ref result))
{
return false;
}
return true;
}

... so it WILL be zero.

Dave
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)

[Luc Pattyn]

That is what the doc[^] says. This entire thread seams to suggest no-one reads or beliefs it. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

[PIEBALDconsult]

Luc Pattyn wrote:

no-one reads or beliefs it

Maybe I'm a one-percenter. :-D My understanding is that all TryParse methods are expected to set the value to zero/null/default(T) when they fail -- so that's what I do when I write a Tryxxx method.

    public bool
    TryParse
    (
        string Name
    ,
        out T  Value
    )
    {
        bool result = true ;

        Value = default(T) ;

public static bool
TryGetValue<T>
(
this object Source
,
out T Value
)
{
bool result = false ;

Value = default(T) ;

[PIEBALDconsult]

Then I prefer to provide a value; something like this:

    public virtual T
    ExecuteScalar<T>
    (
        T IfNull
    )
    {

you could do similar for TryParse.

[PIEBALDconsult]

Eddy Vluggen wrote:

Do we actually care

Not particularly, but we care whether or not it does what the documentation says.

[Luc Pattyn]

I agree. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

[Ravi Bhavnani]

Yessir, it is. /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[Ravi Bhavnani]

Eddy Vluggen wrote:

Do we actually care, if the value isn't being used?

It is being used.  The example I gave was intentionally limited to focus on the question.  In my app, foo (not its real name) is used after the TryParse() executes.  Different things happen depending on whether foo is Decimal.MinValue. /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[Ravi Bhavnani]

You are right in assuming I didn't read the doc. :) /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[dybs]

I think foo would be zero, but that's just a guess. I think Int32.TryParse and Double.TryParse set the out parameter to zero if the parse fails, but I don't recall. If TryParse fails, I usually set the value to some known default that I can handle - I don't care what TryParse sets it to, especially is MS decides to change it down the road.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

[Ravi Bhavnani]

You're absolutely correct.

dybs wrote:

If TryParse fails, I usually set the value to some known default that I can handle

I agree that's the advisable thing to do. /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com