The Weird and The Wonderful

1-Mar-11 4:46

get rid of the var's and then we can talk Laugh | :laugh:

certainly an improvement thou you would be wasting your time checking for result.Equals("0") to end up setting it to 0 anyway, ~~also Convert.ToDouble() will return 0 for empty string anyway~~ (meant that for a null object). Problem is if the result is non-numeric. That's why I would lean more to a (try)parse

SqlCommand cmd = new SqlCommand("...", con);
float result = 0;
float.TryParse(cmd.ExecuteScalar().ToString(), out result);
return result;

I am not saying this is the best best way, but it covers null, empty and non-numeric values

EDIT: as I have correctly been corrected, I should test for null before using ToString() a shameful mistake...

SqlCommand cmd = new SqlCommand("...", con);
float result = 0;
float.TryParse(cmd.ExecuteScalar() AS string, out result);
return result;

GETTING THERE...

SqlCommand cmd = new SqlCommand("...", con);
float result = 0;
object cmdResult = cmd.ExecuteScalar();
if(cmdResult != null)
     float.TryParse(cmdResult.ToString(), out result);
return result;

...of course _Erik_ has the better (and smaller) amount of code

Don't vote my posts down just because you don't understand them - if you lack the superior intelligence that I possess then simply walk away

modified on Wednesday, March 2, 2011 7:10 AM

GibbleCH1-Mar-11 5:56

GibbleCH

1-Mar-11 5:56

I was copying the logic of the OP, like I said, I hadn't tested anything. But reducing the DB access from 3 to 1, will make a HUGE performance gain.

ps. 'var' is gold. I use it everywhere since my variable names are clear, and I refactor a lot. And not having to change types saves a lot of time.

musefan1-Mar-11 6:17

1-Mar-11 6:17

Yep I agree reducing the DB access is definitely the best performance optimisation.

GibbleCH wrote:
I use it everywhere since my variable names are clear

That's fair enough, I just prefer having the type declared at the start as it makes easier scanning IMO

Don't vote my posts down just because you don't understand them - if you lack the superior intelligence that I possess then simply walk away

_Erik_2-Mar-11 0:27

2-Mar-11 0:27

musefan wrote:
float.TryParse(cmd.ExecuteScalar().ToString(), out result);

That will throw a null reference exception if ExecuteScalar returns null.

musefan2-Mar-11 0:44

2-Mar-11 0:44

just testing Poke tongue | ;-P

...perhaps you should put it in a new hall of shame post

Don't vote my posts down just because you don't understand them - if you lack the superior intelligence that I possess then simply walk away

_Erik_2-Mar-11 1:00

Re: Strings: the perfect way to compare numbers. [modified]

2-Mar-11 1:00

Oh, no... We all make this kind of mistakes from time to time. However, the way you have corrected it would not work either. In this case ExecuteScalar would return null or a boxed value type, so checking its result with "as string" would always return null. I you don't use a nullabe type here you would have to use an object and check for null before trying to make any conversion, I mean:

object obj = cmd.ExecuteScalar();
if (obj != null)
   // Now you can make the conversion

I my opinion, nullable types are much cleaner for this.

_Erik_2-Mar-11 0:00

2-Mar-11 0:00

musefan wrote:
...so how would you write that bit of code?

musefan wrote:
Need to get it to a float somehow

int? result = (int?)cmd.ExecuteScalar();
return (float)result.GetValueOrDefault();

There is no need for esoteric conversions, Parsing or ToString at all. Actually, there is no need for an if in the original code posted, and if ExecuteScalar returns null, the original code would throw a null reference exception.

musefan wrote:
What deserves a vote of 1?

I don't know, I did not downvote you.

Edit: Where you see "int?" I put "float?" before, and that was a mistake.

modified on Wednesday, March 2, 2011 6:18 AM

musefan2-Mar-11 0:30

2-Mar-11 0:30

I think you where better of with float, what if SUM returns a double value? Plus int to float can be implicitly cast

I get what you are saying thou. I am not sure on the exact ins and outs of the performances of casting to nullable and using GetValueOrDefault() over an if null statement but I doubt it would be much either way so preference will get the job done

Don't vote my posts down just because you don't understand them - if you lack the superior intelligence that I possess then simply walk away

_Erik_2-Mar-11 0:48

2-Mar-11 0:48

Yup, you are right, I was better with "float?". I did not read the query (as usual, I am soooo absentminded). The nullable type to use must be the one which fits with the one defined into the database, I mean, if the query is defined to return a float you cannot use "double?", becouse the unboxing operation would fail. Anyway, GetValueOrDefault is a constant complexity operation, so in these cases I usually choose the solution which gives me a cleaner implementation.

musefan2-Mar-11 1:24

2-Mar-11 1:24

_Erik_ wrote:
The nullable type to use must be the one which fits with the one defined into the database

I think a nullable float would still do the trick, even if the DB defined the value as decimal or numeric or int or float then the explicit case to float would still work, and as that is your retuning value anyway you need to cast to float at some point

Don't vote my posts down just because you don't understand them - if you lack the superior intelligence that I possess then simply walk away

_Erik_2-Mar-11 1:41

2-Mar-11 1:41

No, that is not right. Just try this:

object obj = 1;
float? f = (float?)obj;

This would throw an exception. The value type boxed into the object in this case is an int, so you need an (int) or (int?) casting to unbox it. Any other type would throw the same exception. Remember we first have to unbox the value type, and the compatibility rules among numeric types are not applied for boxing-unboxing operations.

musefan2-Mar-11 1:51

More on string comparison

2-Mar-11 1:51

oh yes, correct again sir... lesson learnt

Don't vote my posts down just because you don't understand them - if you lack the superior intelligence that I possess then simply walk away

oggenok6424-Feb-11 18:42

oggenok64

24-Feb-11 18:42

Straight out of a C# Unified Communications code sample from MS:

if (string.IsNullOrEmpty(customMessage.Trim()))
  ...

Bernhard Hiller24-Feb-11 21:15

Bernhard Hiller

24-Feb-11 21:15

Looks like somewhen Trim() returned null when a string contained spaces only.
Or was it meant for Oracle compatibility (with Oracle, an empty string means null)?

_Erik_24-Feb-11 23:55

24-Feb-11 23:55

Really funny. The check for a null string will throw a null reference exception is customMessage is null.

musefan25-Feb-11 2:39

25-Feb-11 2:39

What is wrong with that? I imagine this was before .Net 4.0 in which you can now use string.IsNullOrWhitespace()...

if(string.IsNullOrWhitespace(customMessage))
  ...

Illogical thoughts make me ill

Samuel Cragg25-Feb-11 3:52

Samuel Cragg

25-Feb-11 3:52

musefan wrote:
What is wrong with that?

As _Erik_ said, what happens with this code?

string customMessage = null;
if (string.IsNullOrEmpty(customMessage.Trim()))
  ...

musefan25-Feb-11 4:02

25-Feb-11 4:02

now that's shameful coding, but the OP never put that, there is no evidence that it is unsafe to assume that customMessage will never be null. What if the following was the case...

string customMessage = GetCustomMessage();
if (string.IsNullOrEmpty(customMessage.Trim()))
   ...

string GetCustomMessage(){
   string result = GetSomeDataFromSomewhere();
   return result ?? "";//or in times of old... return result == null ? "" : result;
}

Illogical thoughts make me ill

Samuel Cragg25-Feb-11 5:09

Samuel Cragg

25-Feb-11 5:09

musefan wrote:
there is no evidence that it is unsafe to assume that customMessage will never be null

If that was the case then the call to string.IsNullOrEmpty would not be required, as you could safely access the Length property and test for zero. Eitherway you look at it, the OP code is unnecessary Wink | ;)

musefan25-Feb-11 5:21

25-Feb-11 5:21

But the whole point in the trim (IMO) is to test that a complete whitespace string is not confused with meaningful data. Imagine if the string was fetched using my sample method, and the call to get the data in there returns a tab separated list - this function may always end in a tab even when no data has been added. so the resulting value could be "\t" in which case it should be ignored just like "" would be.

Your length test doesn't work in this case because a string of data and whitespace would equal the same. Consider the following possible string values and what you want to test for invalid...

string s = "";//empty and want to handle (length is 0 so fine)
string s = "\t";//as good as empty and want to handle (length is 1 so problem here)
string s = @"data 1\tdata 2\t";//some useful data and this will not be 'caught' by the trim test

Illogical thoughts make me ill

Samuel Cragg25-Feb-11 5:40

Samuel Cragg

25-Feb-11 5:40

Sorry, I don't think I phrased it well. The length test was a replacement for the string.IsNullOrEmpty call - you can still call Trim though. Back to the original code:

// This is the same as the original code - if customMessage
// is null then they'll be an exception
if (customMessage.Trim().Length == 0)
  ...

musefan25-Feb-11 6:00

25-Feb-11 6:00

I see, yep that's OK with me Smile | :)

My initial post was really to find out why it was such a bad line of code when we cannot see any other code to judge. People seemed to be going for the null exception but there was nothing to indicate that ~~would~~could happen

Illogical thoughts make me ill

Re: More on string comparison [modified]

oggenok6425-Feb-11 21:30

oggenok64

25-Feb-11 21:30

However unlikely, things that CAN happen eventually WILL happen. Illogical or not.

musefan28-Feb-11 23:56