I remember being told that you can add some syntax to the end of a statement that will do something if the field is null. Pretty vague, but I cant seem to find anything about it via google.
I definitely isnt how to set a field to be nullable. I know that.
Here is an example of what I want.
int? field1 = 0;
field1 = int.parse(string2); (where string2 is a passed value, that could be null)
I thought there was something you could put at ?? that would help if it is a null, such as:
field1 = int.parse(string2) ??;
Or do I have to check every if every string2 is null before making that statement.
private string userData;
private int intzero;
if (int.TryParse(userData,out intzero))
{
//do something
}
If you don’t want to check for null, you can’t use int.Parse, because it will throw an exception.
At best you can use this, but the previous solution is much better
userData=userData??"0" ;// set a default string value
intzero=int.Parse(userData); // now, userData can't be null but it can be empty :D and you still have to catch an exception
You’d have to explicitly use a field and “normal” property instead of an auto-implemented property:
public class Bob
{
private int value;
public int Value
{
get { return value; }
set { this.value = value; }
}
Then you can pass the field as an out parameter:
Int32.TryParse("123", out bob.value);
But of course, that will only work within the same class, as the field is private (and should be!).
Properties just don’t let you do this. Even in VB where you can pass a property by reference or use it as an out parameter, there’s basically an extra temporary variable.
If you didn’t care about the return value of TryParse, you could always write your own helper method:
static int ParseOrDefault(string text)
{
int tmp;
int.TryParse(text, out tmp);
return tmp;
}
// Then use:
bob.Value = Int32Helper.ParseOrDefault("123");
That way you can use a single temporary variable even if you need to do this in multiple places.
I think I will setup the ParseofDefault method as described above
namespace MyProject.Extensions
{
public static class StringExtensions
{
public static int ParseOrDefault(this string sourceText, int defaultValue = 0)
{
try
{
return int.Parse(sourceText);
}
catch
{
return defaultValue;
}
}
}
}
Now as long you have a using clause for the namespace, all strings have this new method.
string input = "234";
int result = input.ParseOrDefault(); // result = 234
string input = null;
int result = input.ParseOrDefault(); // result = 0
string input = "";
int result = input.ParseOrDefault(); // result = 0
// using a different default value
string input = "";
int result = input.ParseOrDefault(99); // result = 99
It is better to use int.TryParse. Exceptions (when thrown) are horribly slow and may mess up your ability to debug. Only use exceptions for truly exceptional conditions.
Consider somthing like
int value;
if (!int.TryParse(somestring, out value)) value=0;
Yup, whatever.TryParse will not bubble exceptions – that is kind of the point of the method. Instead, it returns false if the value could not be parsed and does not change the value of the out parameter.
Believe it or not, in 1.0 days, how one should parse integers was a matter of huge debate. The old speed tests are still around somewhere.
No - TryParse does not throw exceptions. It is actually the other way around: Parse will call the same methods as TryParse internally but it will validate the results and throw exceptions explicitly.
Exceptions cause stack unwinding and has a considerable overhead when thrown. Installing an exception handler (try-catch block) is very effective as long as exceptions are not actually thrown. You could say that exceptions have been optimized for the the sunshine cases. Which makes sense: You want to make it easy and effective to code robust. After all, you should never expect exceptions - which is kind of implied by the name.