Checking for A Blank String

[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?

 

[ClayB]

You might try using the string.IsNullOrEmpty method to test your
string for null or empty.

==============
Clay Burch
Syncfusion, Inc.

 

[Lloyd Sheen]

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

 

[rowe_newsgroups]

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?

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

 

[Herfried K. Wagner [MVP]]

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?

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
///

 

[\(O\)enone]

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
///

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.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

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.

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

If s.Length > 0 Then
...
End If

 

[Herfried K. Wagner [MVP]]

Göran,

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

If s.Length > 0 Then
...
End If

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.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

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.

Yes, ok, it's almost only a wrapper.

 

[\(O\)enone]

Yes, ok, it's almost only a wrapper.

Perhaps, but the "almost" is the reason I choose to use it over the other
methods.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Perhaps, but the "almost" is the reason I choose to use it over the other
methods.

Why not use String.IsNullOrEmpty()? That is even more specialised for
this situation.

 

[Herfried K. Wagner [MVP]]

Why not use String.IsNullOrEmpty()? That is even more specialised for this
situation.

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?

 

[Tom Leylan]

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?

 

[Herfried K. Wagner [MVP]]

Tom,

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.

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.

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().

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?

Read on here:

DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Unfortunately this method will throw exceptions in certain scenarios

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?

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?

 

[Tom Leylan]

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.

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>

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.

 

[=?windows-1252?Q?G=F6ran_Andersson?=]

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.

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."

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.

 

[Herfried K. Wagner [MVP]]

Tom,

You can look up "robust" in a dictionary and I don't understand why you
didn't.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

 

[Herfried K. Wagner [MVP]]

Göran,

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.

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.

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

 

[Herfried K. Wagner [MVP]]

Göran,

Can you give one single example where it would throw an exception?

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?

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