For this code, how do you know that null is returned if there is no value in the querystring?
HttpContext context = HttpContext.Current;
string strValue = context.Request[name];
I'm asking because I never know what's being returned in many cases in the .NET framework when you don't get the value expected when it does not exist.
so if context.Request[name]; is called and the name doesn't exist in the querystring, how do you know it returns null or an empty string so that I can properly handle the case where it does not exist?
Use String.IsNullOrEmpty() to check for a Null or Empty string.:
string strValue = !String.IsNullOrEmpty(context.Request[name]) ??
context.Request[name] : "Some Default Value";
Or if you don't have a default value you'd like to set, you can do the check later:
if(String.IsNullOrEmpty(strValue))
{
// It's Null Or Empty
}
else
{
// It's Not
}
Update
Just saw the comment. If you're trying to figure out if referencing a key that doesn't exist in the Params collection (which is what you're using via shorthand), then check the MSDN documentation.
In this case, Params is a System.Collections.Specialized.NavmeValueCollection. The documentation is here. According to the documentation, a null value is indeed returned when a key is not found in the collection.
Therefore you don't have to use String.IsNullOrEmpty(). You could just:
string strValue = context.Request[name] ?? "Some Default Value";
If you want to set a default, or check for null otherwise.
As #Justin Niessner says, you can check the context.Request[name] for null as you read it. This is perfectly efficient and reasonable.
If you feel uncomfortable working with nulls, you can examine the collection into which name is the index.
In your example, context.Request[name] is shorthand for context.Request.Params[name]. Params is a NameValueCollection, which in turn has a property AllKeys. Assuming we're using .NET 3.5 you can then use .Contains() like so:
if (context.Request.Params.AllKeys.Contains(name))
{
// do something
}
Also, you specifically mention you're interested in the query string. context.Request[] returns not just the query string, but also Cookies, Form and ServerVariables. For the query string, use
if (context.Request.QueryString.AllKeys.Contains(name))
{
// do something
}
I think what you are asking is 'how do I know what the behaviour of this object is?' - in which case I don't know of a better answer than 'check the documentation' - in this case, HttpContext.Request is documented as being of type HttpRequest, which in turn is documented as having an Item method for which the documentation says:
If the specified key is not found, then a null reference (Nothing in Visual Basic) is returned.
What I can't immediately see is how you would light on the Item method specifically as the name of the indexer (this[]) method if you didn't know that that was a standard convention...
Request.Params is a NameValueCollection, which will return 'null' if a key does not exist in the collection.
So, if the URL was:
http://localhost
Then context.Request.Params["foo"] would be null.
Now, if the request was:
http://localhost?foo=
Then context.Request.Params["foo"] would be "".
I think this is what you are looking for.
You can do something like this using Extension Methods:
if(!Request["Name"].IsNullOrEmpty())
{
// do something with the Request["Name"] value
// OR
// You can extract the Request["Name"] into a variable and do the same with the variable
}
The ExtentionMethod look something like this:
public static bool IsNullOrEmpty(this string str)
{
return String.IsNullOrEmpty(str);
}
Thanks!
Related
I want to make a method that gives a string (input in method) the value null. This is for my database, so that there are no 'open' values.
It needs to be something like this:
public string NulValue (string value)
{
value = null; //the string-value needs to get the value null here
return value; //returning the value
}
But this is not giving the string the value null. I think the solution is very easy, but I don't get it to work. I use WPF.
Here is where I want to use the method:
string checkcomment = TextBxComment.Text;
if (checkcomment == "")
{
NulValue(checkcomment);
}
You can not make a string anything. While strings are reference types, they are on that is designed to work like Value Type for many purposes. Do not try to learn class semantics with string. You can however set the reference to null, wich works similar to setting a value type to anything in a function.
By default functions use "call by value", wich means a copy of the Primitive Type or Reference variable is made. And you then work with that copy. In order to force a function to use call by reference (in wich the actually variable is re-used and can be modified), the ref and out keywords are used for that.
However teh whole operation makes little sense. As far as you example code shows, you want to set the reference variable to null. At wich point
myValue = null;
will always be easier to write and read then
NullValue(ref myValue);
But of course there might be some logic you have not shown us.
Properties can not be used as ref values. So if you use properties, you have to write somewhat more code.:
var temp = Instance.MyValue;
NullValue(ref temp);
Instance.MyValue = temp;
With a Database, this might be about mapping the .NET Type/Value Null to the Databases Type/value Null. Wich can be very different things.
From MSDN doc:
public bool Contains(
string value
)
Return Value: true if the value parameter occurs within this string, or if value is the empty string (""); otherwise, false.
Exception: ArgumentNullException: value is null.
Example:
string s = string.Empty; //or string s = "";
Console.WriteLine(s.Contains("Hello World!")); //output: False
If I change it to:
try
{
string s = null; //or string s;
Console.WriteLine(s.Contains("Hello World!"));
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
It'll throw an error message: Object reference not set to an instance of an object since string doesn't have a default value (like "") from Default Values Table (C# Reference),
Please come back to the example, the code will work if I declare s:
string s = "";
Now, Object s is set to an instance of an object.
So, my question is: Does MSDN forgot something like: s cannot be null?
To check it, I've tried:
string s = null;
Console.WriteLine(!string.IsNullOrEmpty(s) ? s.Contains("Hello World!") : false);
It should work.
You changed the value with the instance.
myString.Contains(anotherString)
Here myString is the instance on which you call the method Contains, whereas anotherString is the value passed to the method. If this value is null the method will throw an ArgumentNullException.
When changing the instance to null on the other hand it surely leads to NRE as you can´t call any member on a null-reference. However if you set it to string.empty Contains will return false because the empty string does not contain anything (in particular string.empty does not contain "Hello World", however "Hello world" contains the empty string).
So the following returns false:
Console.WriteLine(string.Empty.Contains("Hello World"));
Whilst this returns true:
Console.WriteLine("Hello World".Contains(string.Empty));
Anyway what you want to check is if the empty string IS contained in any other one:
var retVal = myString.Contains(string.empty);
Which should return true.
Furthermore myString.Contains(null) leads to ArgumentNullException
On the other side null.Contains(aString) leads to the NRE.
the new compilier allows you to do it with the condition check simplified.
string s = null;
Console.WriteLine(s?.Contains("Hello World!"));
It sounds like this question is more about the difference between value types (which cannot be null) and reference types (which can be). In C# and other OO languages it's to do with memory handling.
The value types listed in your MSDN article are all of a known size - e.g. int will always be 32 bits in size etc. Under the hood, these are all structs. As they are of fixed size regardless of the value, C# stores them on the call stack. As null by definition doesn't refer to anything, it has no size. It doesn't make sense for something that exists with a fixed size to also exist with no size.
If you read the documentation for string on MSDN a little closer, you'll see the string is a class not a struct. This is because a string can be of any length you like, so it has to be stored as a pointer to some data on the heap. When you declare a reference type variable, it creates a pointer on the stack to a location on the heap, but there won't be anything at that address until you give that variable a value. Until then, the pointer for that variable is pointing and memory containing literally nothing - i.e. null and it doesn't make sense to try to find "Hello World!" in nothing. An empty string is still a string, but null is literally nothing.
This is probably more detail than you were expecting, but it's good to have an appreciation of the underlying principles of a language, even if you don't need them day to day. This article is well worth a read if you want to go a little more in depth. The idea of null can be a weird concept to get your head around, but once you get the hang of it, it all makes sense, honest!
I have seen the below code. I understand what it's doing. It gets a list of enum and then matches it with value passed and returns the matched one. What is this shorthand called? Is there a link a to more advanced short hands like this?
string a = null;
a = getListOfEnums()["matching value"];
Edit
It does not need to be an enum. It can be a dictionary object (key value pair) too.
Are you sure about the code? In current form the only way it may work is that getListOfEnums() returns a delegate that takes a string and returns a string. That wouldn't match name of the method, so I don't think that's the case.
What I think you're talking about is indexer:
string a = null;
a = getListOfEnums()["matching value"];
What's the preferred way of checking if the value is null?
Let's say we have some entity, which has properties, which can be null (some of them or all of them).
And I wish to check this in runtime, if some property is actually null or not.
Would you use simple Entity.Property != null check in this case or would you implement a specific method, let's say like
bool HasProperty() {
return Property != null;
}
What would you choose and why?
For property values which can be null, my preference is to do the following
Have the property containing the value which can possibly be null
Have another property prefixed with Has and the rest containing the original property name which determines if the other property is non-null
Add an assert into the original property if it's accessed when null
In this example it would be
SomeType Property {
get {
Contract.Requires(HasProperty);
return _property; }
}
bool HasProperty {
get { return _property != null; }
}
The reasoning behind this is that C# does not have a standard way of describing whether or not a value can be null. There are many different conventions and techniques avalaible but simply no standard. And not understanding the null semantics around a value leads to missed null checks and eventually NullReferenceExceptions.
I've found the best way to express this is to make the null feature of a property explicit in the type itself by adding the Has property if and only if the property can be null. It's not a perfect solution but I've found it works well in large projects.
Other solutions I've tried
Do Nothing: This just fails over and over again
Using an explicit Maybe<T> or Option<T> type in the flavor of F#. This works but I find I receive a lot of push-back from developers who've never done functional programming and it leads to a rejection of the idea entirely in favor of #1.
Just check if the property itself is null, there is no need to create a method for this. Properties are really just methods that are generated by the compiler.
There is no pattern that covers this. In fact, anything you do to try and make this "easier" could be considered an anti-pattern.
"Hey, don't check if the property is null, use the Is[Property Name]Null property"
Uh, no.
I check only against null, because every nullable type does internally exactly what you described (but the internal method is called HasValue instead of HasProperty):
http://msdn.microsoft.com/de-de/library/b3h38hb0.aspx
If Property is something that isn't public, then you would need a method like HasProperty(). Also, if you implement your "nullness" in another way, it would also be good to have a HasProperty() method.
Null is not necessarily bad. I think it all depends on why you need to check for null to determine how you should check for it.
I would choose to write a separate Has* property only if the property is auto-initializing (i.e. just getting it might cause, say, an empty collection to be allocated) and it makes a performance difference. If getting the property is cheap (as it should be; in some cases you just can't help having it make a difference, though), there's no need for a superfluous Has method.
So no Has for the general case:
public string Foo { get; set; }
But in some cases, it can be a good idea:
private List<string> someStrings = null;
public List<string> SomeStrings {
get {
if (someStrings == null)
someStrings = new List<string>();
return someStrings;
}
}
public bool HasSomeStrings {
get { return (someStrings != null && someStrings.Count > 0); }
}
I have seen different ways to retrieve a string field from SQL. Is there a "right" way, and what are the differences
SqlDataReader rdr;
1. String field = (String) rdr["field"];
2. String field = rdr["field"].ToString();
3. String field = rdr["field"] As String;
Thanks!
You could also use:
int ordinal=rdr.GetOrdinal("stringField");
if (rdr.IsDBNull(ordinal))
{
return string.Empty; //Or null or however you want to handle it
}
else
{
rdr.GetString(ordinal);
}
Which if you look at the definition for SQlDataReader["field"] looks like:
public override object this[string name]
{
get
{
return this.GetValue(this.GetOrdinal(name));
}
}
Essentially this is doing the same thing, only it's type safe. What I like to do is Create my own IDataReader which wraps SqlDataReader. CSLA uses a simillar mechanism that they call SafeDataReader since it provides overloads for all the various data types which implements this pattern.
If you know the field won't be null you could leave out the isDbNull checks. Due to the verbosity I'd recommend putting this in some type of wrapper or helper class and make functions out of them.
May cause an exception if the type is not string
Is definitely wrong because that could raise an exception if the value is null.
Will assign null if it is null or if it is of type other than string
So, to be on the safe side - I would choose 3.
Keep in mind that the question interacts with your data definitions. If "field" has been defined as "Not Null" then you don't have to worry about null data and should choose #1 for readability. Similarly, if the field is nullable but you use an "IsNull" function when doing your query:
Select IsNull(Field1, '') as Field1 From DBTable Where...
then, again, you should choose #1 because you still don't have to worry about null. Of course, this assumes that you would WANT the null value to be masked by the empty string. If you want to test against null because it is an error condition then you'd have logic like:
if (nwReader.IsDBNull(nwReader.GetOrdinal("Field1")))
*throw exception or otherwise handle null condition
string aStr = (string)nwReader["field"];
This last case, however, is not really good practice. If null is an invalid value - an error condition - then you should rule it out in your DDL.
In the end, though, I always go for option #1 because I think it leads to better readability and it forces me to make my null handling explicit.
If I'm expecting a string, I'll do #1. If for some reason the field isn't a string or changes type, you'll at least know about it through the exception mechanism. (Just don't wrap it inside of a try / empty catch.)
I like the ?? operator for checking nulls (as discussed in other posts)
String field = rdr["field"] As String ?? string.Empty
This should work. If not, well its late :P, unless you actually want the result to be null. If so then I like 3.