empty string paramters rather than nulls

[Jacob]

Is there any way (maybe using an attribute) that I can force strings or
other reference parameters to always have an instance even if they are
blank? Ex:

[WebMethod]
public string DoSomething(string Text)
{
if (Text != null) /// i would like to avoid checks like this. they get
to be annoying when passing a lot of strings
DoWork();
}

If a blank string is passed to this function, the framework won't create a
string instance. I would prefer that it did so I wouldn't have to pepper my
code with != null checks.

[Valentin]

Try the following code

[WebMethod]
public string DoIt(string text)
{
if (text.Length != 0)
DoThat ();
return ...;
}

Have a fun!

Valentin

Do not hesitate to contact me!

www.wwv-it.eu
va*************@t-online.de

"Jacob" wrote:

Is there any way (maybe using an attribute) that I can force strings or
other reference parameters to always have an instance even if they are
blank? Ex:

[WebMethod]
public string DoSomething(string Text)
{
if (Text != null) /// i would like to avoid checks like this. they get
to be annoying when passing a lot of strings
DoWork();
}

If a blank string is passed to this function, the framework won't create a
string instance. I would prefer that it did so I wouldn't have to pepper my
code with != null checks.

[Jacob]

Wouldn't that be calling null.Length if someone passed a blanks string and
generating an exception?

Try the following code

[WebMethod]
public string DoIt(string text)
{
if (text.Length != 0)
DoThat ();
return ...;
}

[Valentin]

The previous code generate no exception for blanks strings.

The following code does not generate any exception even when the input
string is a null string.

[WebMethod]
public string DoIt(string text)
{
try
{
if (text.Length != 0)
{
DoThat ();
return "OK";
}
else return "Length = 0";
}
catch
{
return "Null string";
}

}

Have a fun!

Valentin

Do not hesitate to contact me!

www.wwv-it.eu
va*************@t-online.de
"Jacob" wrote:

Wouldn't that be calling null.Length if someone passed a blanks string and
generating an exception?

Try the following code

[WebMethod]
public string DoIt(string text)
{
if (text.Length != 0)
DoThat ();
return ...;
}

[Valentin]

A little bit improving

[WebMethod]
public string DoIt(string text)
{
int i;
try
{
i = text.Length;
if (i != 0)
{
DoThat ();
return i.ToString ();
}
else return "0";
}
catch
{
return "Null string";
}
"Valentin" wrote:

The previous code generate no exception for blanks strings.

The following code does not generate any exception even when the input
string is a null string.

[WebMethod]
public string DoIt(string text)
{
try
{
if (text.Length != 0)
{
DoThat ();
return "OK";
}
else return "Length = 0";
}
catch
{
return "Null string";
}

}

Have a fun!

Valentin

Do not hesitate to contact me!

www.wwv-it.eu
va*************@t-online.de
"Jacob" wrote:

Wouldn't that be calling null.Length if someone passed a blanks string and
generating an exception?

Try the following code

[WebMethod]
public string DoIt(string text)
{
if (text.Length != 0)
DoThat ();
return ...;
}

[Mark Wilden]

I would simply check for text == null rather than catching an exception. It
is faster and better expresses the intent of the code. This code also
returns "Null string" if DoThat() throws any exception.

Exceptions should not be used for control flow, but to catch unanticipated
problems.

"Valentin" <Va******@discussions.microsoft.com> wrote in message
news:60**********************************@microsof t.com...

A little bit improving

[WebMethod]
public string DoIt(string text)
{
int i;
try
{
i = text.Length;
if (i != 0)
{
DoThat ();
return i.ToString ();
}
else return "0";
}
catch
{
return "Null string";
}

[Valentin]

Jacob wants even to avoid the null / not null test (Text == null / Text !=
null). See his question.
There is no restriction how to use the exceptions. Of course they must not
be redundant to system-defined exceptions. But a custom exception can
substitute, for instance, a test of null or 0. What is the problem? In both
cases the method will return with a message string indicating an error.
Sometimes a custom exception (try … operation …catch …error message) is more
simply than a usual test followed by a message error (if true) or by the
operation (if false) .
My code was just an example. Of course DoThat could throw exceptions, if the
method itself is not provided with all tests. But this was not the problem.
See Jacobs question.
Any the DoThat method could be also included in a try …. catch … finally
sequence.
But again this was not the problem.

Valentin
IT-Bachelor
Microsoft Certified Professional
"Mark Wilden" wrote:

I would simply check for text == null rather than catching an exception. It
is faster and better expresses the intent of the code. This code also
returns "Null string" if DoThat() throws any exception.

Exceptions should not be used for control flow, but to catch unanticipated
problems.

"Valentin" <Va******@discussions.microsoft.com> wrote in message
news:60**********************************@microsof t.com...

A little bit improving

[WebMethod]
public string DoIt(string text)
{
int i;
try
{
i = text.Length;
if (i != 0)
{
DoThat ();
return i.ToString ();
}
else return "0";
}
catch
{
return "Null string";
}

[Mark Wilden]

From: "Valentin" <Va******@discussions.microsoft.com>

Jacob wants even to avoid the null / not null test (Text == null / Text
!=
null). See his question.
You're right. My mistake.
There is no restriction how to use the exceptions.
There are accepted practices, however. This isn't one of them. And for good
reason - throwing an exception is much slower than performing a comparison.
Catching an exception is much less clear, as well.
My code was just an example. Of course DoThat could throw exceptions, if
the
method itself is not provided with all tests. But this was not the
problem.
This is a good example of why one should always catch the most derived
Exception possible.
Any the DoThat method could be also included in a try .. catch . finally
sequence.

What a waste, just to avoid a comparison to null!

In any event, if the goal is to avoid null or empty strings,
String.IsNullOrEmpty() should be used. Code should say what it means to do.

///ark

[Jacob]

The previous code generate no exception for blanks strings.

But it appears (at least in my test) that when someone passes a blank string
parameter to my web service

e.g. <SomeStringParameter/>

the receiving web service doesn't create a blank 0 length string instance.
Instead it receives a null string reference. Which means I then have to be
putting in checks for the null to avoid the "object reference not set to an
isntance of an object" errors that wouldn't be raised if there was a blank
instance.

Ideally I wanted to know if you could set some sort of pre condition
attribute so that the framework would always create an instance (even if it
was empty) when passing in strings, or arrays, or other reference objects.

I think the quickest thing for me to do is to add this type of fix at the
top of the function:

if (stringparameter == null) stringparamter = "";

But it seems a little silly.

[Valentin]

I am working with Microsoft Visual C# .NET 2003
It has not the method String.IsNullOrEmpty().
And now it is really a waste this discussion.

Valentin
"Mark Wilden" wrote:

From: "Valentin" <Va******@discussions.microsoft.com>

Jacob wants even to avoid the null / not null test (Text == null / Text
!=
null). See his question.

You're right. My mistake.

There is no restriction how to use the exceptions.

There are accepted practices, however. This isn't one of them. And for good
reason - throwing an exception is much slower than performing a comparison.
Catching an exception is much less clear, as well.

My code was just an example. Of course DoThat could throw exceptions, if
the
method itself is not provided with all tests. But this was not the
problem.

This is a good example of why one should always catch the most derived
Exception possible.

Any the DoThat method could be also included in a try .. catch . finally
sequence.

What a waste, just to avoid a comparison to null!

In any event, if the goal is to avoid null or empty strings,
String.IsNullOrEmpty() should be used. Code should say what it means to do.

///ark