Checking for A Blank String

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have an if statement that isn't working correctly and I was wondering how I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not enter
my IF statement like I would think it should. How do I properly check for a
blank variable?
 
You might try using the string.IsNullOrEmpty method to test your
string for null or empty.

==============
Clay Burch
Syncfusion, Inc.
 
What you are doing is correct. A more VB way is to check the string against
String.Empty.

If it is not entering the if code then there is something other than "" or
String.Empty in the field.

Lloyd Sheen
 
I have an if statement that isn't working correctly and I was wondering how I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not enter
my IF statement like I would think it should. How do I properly check for a
blank variable?

How do I properly check for a blank variable?
Click to expand...

Are you checking for a blank variable or blank string? If the former
use myVar is nothing the latter you should use
String.IsNullOrEmpty(myStringVar)

Thanks,

Seth Rowe
 
Playa said:
I have an if statement that isn't working correctly and I was wondering how
I
check for a blank string.
My Code Example

if me.fieldname(arrayIndex) = "" then
-----
end if

When I do this and there is no characters in the variable it does not
enter
my IF statement like I would think it should. How do I properly check for
a
blank variable?
Click to expand...

If you want to check if your variable is not 'Nothing' and does not contain
an empty string:

\\\
If Len(s) > 0 Then
...
End If
///
 
Herfried said:
If you want to check if your variable is not 'Nothing' and does not
contain an empty string:

\\\
If Len(s) > 0 Then
...
End If
///
Click to expand...

This is my recommended way too. For all the new features and functionality
offered in .NET, I'll still go for good ol' Len() every time.
 
(O)enone said:
This is my recommended way too. For all the new features and functionality
offered in .NET, I'll still go for good ol' Len() every time.
Click to expand...

The Len function is just a wrapper for the String.Length method.

If s.Length > 0 Then
...
End If
 
Göran,

Göran Andersson said:
The Len function is just a wrapper for the String.Length method.

If s.Length > 0 Then
...
End If
Click to expand...

No, it's more than that. It will return 0 if the value passed to it is
'Nothing'. The code you posted would throw a 'NullReferenceException' in
this case.
 
Herfried said:
Göran,



No, it's more than that. It will return 0 if the value passed to it is
'Nothing'. The code you posted would throw a 'NullReferenceException'
in this case.
Click to expand...

Yes, ok, it's almost only a wrapper.
 
(O)enone said:
Perhaps, but the "almost" is the reason I choose to use it over the other
methods.
Click to expand...

Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.
 
Göran Andersson said:
Why not use String.IsNullOrEmpty()? That is even more specialised for this
situation.
Click to expand...

Unfortunately this method will throw exceptions in certain scenarios and
it's much more to type and read. Why choose the compilated solution over
the simpler one?
 
Let me ask others to consider that "time-to-type" shouldn't be a major
consideration when developing applications. Yes if you are in a typing
contest but no if you are trying to write robust software for a living.

The reason one would choose a "complicated" solution if we honestly consider
typing IsNullOrEmpty complicated is to gain plainness and transparency.
There is nothing about a function named Len() which suggests that it is
testing for Null values and code which disguises what is happening is among
the worst kinds of code.

Using "plain", "simple", "obvious" and "easy-to-understand" as criteria let
each developer ask him/herself what does IsNullOrEmpty() test for and what
is it's return value. If you find it hard to figure out based upon it's
name then by all means choose Len().

I'd also be interested to know which "certain scenarios" throw exceptions I
didn't see it mentioned in the docs. Which exception does it throw?
 
Tom,

Tom Leylan said:
Let me ask others to consider that "time-to-type" shouldn't be a major
consideration when developing applications. Yes if you are in a typing
contest but no if you are trying to write robust software for a living.
Click to expand...

Why should using 'Len' be "less robust" (whatever that means)? The behavior
of 'Len' is well-known to anybody using BASIC for years and it's documented
too. Additionally, 'Len' is a 1st class citizen in VB. 'Len' feels much
more natural in VB than the "low-level" method 'IsNullOrEmpty', especially
because the term/keyword 'null' is not used in VB.
The reason one would choose a "complicated" solution if we honestly
consider typing IsNullOrEmpty complicated is to gain plainness and
transparency. There is nothing about a function named Len() which suggests
that it is testing for Null values and code which disguises what is
happening is among the worst kinds of code.
Click to expand...

Well, that's the common behavior of almost all functions contained in the
'Strings' module.

Trying to avoid the use of VB's intrinsic functions is like trying to use a
screwdriver to screw in a nail although there is a hammer in the toolbox for
the reason that "a screwdriver is a more professional tool than a hammer."
Using "plain", "simple", "obvious" and "easy-to-understand" as criteria
let each developer ask him/herself what does IsNullOrEmpty() test for and
what is it's return value. If you find it hard to figure out based upon
it's name then by all means choose Len().
Click to expand...

I doubt that any VB developer using the full repertoire available in the VB
"toolbox" will have problems to understand what 'Len' is doing. I also
believe that I can expect such knowledge from someone claming to know VB.
I'd also be interested to know which "certain scenarios" throw exceptions
I didn't see it mentioned in the docs. Which exception does it throw?
Click to expand...

Read on here:

DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>
 
Herfried said:
Unfortunately this method will throw exceptions in certain scenarios
Click to expand...

Can you give one single example where it would throw an exception?
and
it's much more to type and read. Why choose the compilated solution
over the simpler one?
Click to expand...

I ask the same. When there is already a method available in the standard
libraries that does exactly what you want to do, why use another library
that has a wrapper for a different method that does half of what you
want to do?
 
Herfried:

Each developer must ask him/herself a number of questions before making a
coding decision. If a person develops software by himself for use by a
small company with 25 employees the decisions made will differ from those of
a person who codes in a team of 25 developers that distributes the final
software to 3000 customer locations.

You can look up "robust" in a dictionary and I don't understand why you
didn't. I of course never wrote that the Len() function was "less robust"
but that trick can often work in a discussion so I admire your attempt.
Have you distributed your software to 3000 locations? When you found a bug
did you pick up the costs associated with redistribution? It should be
clear that "typing fast" isn't the issue but rather correctness, robustness,
verifiability, etc. are. These may not be as important if one is the
company "computer guru" and can walk over to secretary's machine to install
your new VB.Net utility but they are to many of us.

Software development (as I have found it) isn't about memorizing the
behavior of the functions in a particular language. If that were the most
important thing those of us who write software solutions wouldn't get much
done. I suggest it is only the MVP who knows what the 3rd parameter of
every multi-parameter function is and while that is an admirable feat it is
not my goal. My goal is to accept the contract to convert my app from
VB.Net to C# and to complete the task so I can get paid. My goal is to
re-engineer the Java app into VB.net and to complete the task so I can get
paid. My goal is not to save 7 characters when I type.

Null may not exist as a keyword but surely you aren't suggesting that VB
developers don't know the concept, right? So "nothing" is the keyword,
again I caution against memorization and vote in favor of learning concepts
rather than (or at least in addition to) syntax.

And of course it is nothing like using a screwdriver to hammer in a nail and
most definitely not due to some ranking of the tools in the toolbox. What
you are describing is the importance of using the hammer that is marked as
"VB.Net" and avoiding at all cost the hammer marked ".Net Framework". Your
special hammer is better than the hammer everybody else is using.
I doubt that any VB developer using the full repertoire available in the
VB "toolbox" will have problems to understand what 'Len' is doing. I also
believe that I can expect such knowledge from someone claming to know VB.
Click to expand...

These particular doubts are unfounded. If you worked with software
developers for any length of time you will find that what they know varies
considerably. After you've looked up robust, take a moment to consider the
number of people posting questions here which on the surface seem trivial.
Many of these could be answered by checking the docs, a great number are
posted by working developers. You're making statements that have no basis
in fact in an attempt to "win" a discussion.

Again (for the record) generally when I reply to you it is not to enlighten
you as I expect only the VB-side of the story in your rebuttal but rather to
influence others who may wish to become more than a "VB programmer" and
aspire to becoming a software developer who uses VB. Furthermore I ask that
readers simply take note of your use of the terms harder, low-level and
complicated when something isn't VB and easy, fast, etc. when it is VB.
DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>
Click to expand...

The link is appreciated. Now any reader with a concern can see plainly that
it does not in fact throw exceptions "in certain circumstances" but (if the
article is correct) will throw an exception in one particular case. The
author concludes "... in all fairness, this is actually a JIT optimization
problem that impacts both VB and C#" and a respondent claiming to be a
tester notes that "it most likely a bug on our side" and that they are
looking into it.

Let me let you in on something, there are bugs in the .Net Framework and
here is a secret, optimizers can make mistakes.

To other readers I'll suggest one avoid making rash coding decisions based
upon a bug. Work around the bug, it will be patched. Other bugs will turn
up in time, such is the life of a programmer. If there was never a bug in a
VB library then by all means limit your development to VB and never use
anything else (perhaps join the pro VB6 rant of at least one poster) because
you have truly found the one great solution.

For everybody else, raise your eyes and take a look out over the development
horizon. All tools are available to you including VB.Net of course.
 
Herfried said:
Why should using 'Len' be "less robust" (whatever that means)? The
behavior of 'Len' is well-known to anybody using BASIC for years and
it's documented too. Additionally, 'Len' is a 1st class citizen in VB.
'Len' feels much more natural in VB than the "low-level" method
'IsNullOrEmpty', especially because the term/keyword 'null' is not used
in VB.
Click to expand...

We are now in VB.NET, not in VB6. What was is no longer. In .NET the
members of the System namespace is the first class citizens.
Trying to avoid the use of VB's intrinsic functions is like trying to
use a screwdriver to screw in a nail although there is a hammer in the
toolbox for the reason that "a screwdriver is a more professional tool
than a hammer."
Click to expand...

That would be true if the .NET alternative was significantly less suited
for what you are trying to do.

In this case it's actually the opposite. The .NET alternative does
exactly what you want to do, while the VB6-like alternative returns a
value that has to be analysed to come to the same result.
 
Tom,

Tom Leylan said:
You can look up "robust" in a dictionary and I don't understand why you
didn't.
Click to expand...

I know the meaning of "robust". The whole discussion is now about using
'Len' vs. 'String.IsNullOrEmpty'. It's pretty clear that the shortest
solution is not always the most robust one. However, I do not see the
relation to my preference of 'Len'. 'Len' is faster to type and read and I
do not consider it less robust than 'String.IsNullOrEmpty'.
I of course never wrote that the Len() function was "less robust" but that
trick can often work in a discussion so I admire your attempt.
Click to expand...

Well, then I suggest you specify more clearly what you are talking about.
Have you distributed your software to 3000 locations? When you found a
bug did you pick up the costs associated with redistribution?
Click to expand...

Where's the relation to the topic?
It should be clear that "typing fast" isn't the issue but rather
correctness, robustness, verifiability, etc. are.
Click to expand...

I consider both 'Len', 'String.IsNullOrEmpty' and 's IsNot Nothing AndAlso
s.Length > 0' correct and robust solutions (lets forget the 'IsNullOrEmpty'
JITter bug here). So this calculus is not of much use here. That's why I
am using a different one: Ease of writing and reading.
Software development (as I have found it) isn't about memorizing the
behavior of the functions in a particular language. If that were the most
important thing those of us who write software solutions wouldn't get much
done.
Click to expand...

Then I am wondering how you are writing code at all.
not my goal. My goal is to accept the contract to convert my app from
VB.Net to C# and to complete the task so I can get paid. My goal is to
re-engineer the Java app into VB.net and to complete the task so I can get
paid. My goal is not to save 7 characters when I type.
Click to expand...

I believe anybody is free to use 'Len' or not. However, I do not see the
problem you are having with it. 'Len' can be converted to another
programming language as easily as 'String.IsNullOrEmpty'.
Null may not exist as a keyword but surely you aren't suggesting that VB
developers don't know the concept, right? So "nothing" is the keyword,
again I caution against memorization and vote in favor of learning
concepts rather than (or at least in addition to) syntax.
Click to expand...

Hm... This point was intended as a joke. No, I really do /not/ think this
is a valid reason not to use 'String.IsNullOrEmpty', as I do not see the
naming and behavior as a reason for abandoning it from the toolbox.
And of course it is nothing like using a screwdriver to hammer in a nail
and most definitely not due to some ranking of the tools in the toolbox.
What you are describing is the importance of using the hammer that is
marked as "VB.Net" and avoiding at all cost the hammer marked ".Net
Framework". Your special hammer is better than the hammer everybody else
is using.
Click to expand...

I gave the reasons why I prefer 'Len' over 'String.IsNullOrEmpty' in my
previous post. There is at least one technical reason that prevents me from
using 'String.IsNullOrEmpty'. My toolbox contains both the Visual Basic
Runtime Library and the .NET Framework Class Library and I do not have a
general (ideological) preference which tools to choose.
These particular doubts are unfounded. If you worked with software
developers for any length of time you will find that what they know varies
considerably. After you've looked up robust, take a moment to consider
the number of people posting questions here which on the surface seem
trivial. Many of these could be answered by checking the docs, a great
number are posted by working developers. You're making statements that
have no basis in fact in an attempt to "win" a discussion.
Click to expand...

I do not want to win anything. It seems that you see discussions as fights
instead of what they are -- just discussions. Be assured that I know that
many developers don't have much knowledge about the tools they are using.
However, as I said, there is no problem 'Len' has and 'String.IsNullOrEmpty'
doesn't have.
Again (for the record) generally when I reply to you it is not to
enlighten you as I expect only the VB-side of the story in your rebuttal
but rather to influence others who may wish to become more than a "VB
programmer" and aspire to becoming a software developer who uses VB.
Furthermore I ask that readers simply take note of your use of the terms
harder, low-level and complicated when something isn't VB and easy, fast,
etc. when it is VB.
Click to expand...

These points are all ungrounded prejudices, none of them apply. I am
actually using different programming languages and I prefer use the tools
they provide. The .NET Framework's method has been considered "low-level"
because the VB.NET class library and other libraries are built on top of the
..NET Framework's classes, often providing access on a higher level, as .NET
programming languages like VB.NET and C# do over IL.
The link is appreciated. Now any reader with a concern can see plainly
that it does not in fact throw exceptions "in certain circumstances" but
(if the article is correct) will throw an exception in one particular
case.
Click to expand...

At least to me as a non-native English speaker this means the same.
However, I only remembered that there was a problem with this method and I
didn't remember which one it was. I had to look for the article again to
see what it has been about (the JITter making problems with this method).
Let me let you in on something, there are bugs in the .Net Framework and
here is a secret, optimizers can make mistakes.

To other readers I'll suggest one avoid making rash coding decisions based
upon a bug. Work around the bug, it will be patched. Other bugs will
turn up in time, such is the life of a programmer. If there was never a
bug in a VB library then by all means limit your development to VB and
never use anything else (perhaps join the pro VB6 rant of at least one
poster) because you have truly found the one great solution.
Click to expand...

If there are two ways to archieve a certain thing and one of them is faulty,
why choose the faulty one? It seems that your decisions are much more based
on ideology than mine. I use 'Len' because there are problems attached with
another way to archieve the same thing and you are wrongly extrapolating
that to a general preference of VB's functions over the .NET Framework.
For everybody else, raise your eyes and take a look out over the
development horizon. All tools are available to you including VB.Net of
course.
Click to expand...

I 100 % agree, but this even includes using the tools VB provides over the
tools of the .NET Framework if their use has advantages.
 
Göran,

Göran Andersson said:
We are now in VB.NET, not in VB6. What was is no longer. In .NET the
members of the System namespace is the first class citizens.
Click to expand...

Who's defining that? In VB.NET both the VB Runtime Library and the .NET
Framework Class Library are fist class citizens and there is no general rule
when to prefer one over the other.
That would be true if the .NET alternative was significantly less suited
for what you are trying to do.

In this case it's actually the opposite. The .NET alternative does exactly
what you want to do, while the VB6-like alternative returns a value that
has to be analysed to come to the same result.
Click to expand...

Re-read my post. I gave a technical reason why I am preferring 'Len' in
this particular case.
 
Göran,

Göran Andersson said:
Can you give one single example where it would throw an exception?
Click to expand...

DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
I ask the same. When there is already a method available in the standard
libraries that does exactly what you want to do, why use another library
that has a wrapper for a different method that does half of what you want
to do?
Click to expand...

Because 'String.IsNullOrEmpty' can lead to potential problems at runtime. I
am not saying that 'String.IsNullOrEmpty' should never be used under all
circumstances.
 
Back
Top