Develop Reference

How do you check for nullable value in an if statement

I have the following code:
string thing="";
if(request.Session.Attributes?.TryGetValue("varName", out thing))
{
//do stuff
}
request.Session.Attributes is a dictionary.
I understand that you can't have if(bool?) which is what the above does.
I also know that you can have .GetValueOrDefault() so that null will be treated as false.
But I can't do request.Session.Attributes?.GetValueOrDefault().TryGetValue("varName", out thing)
So what is the correct way to return false if Attributes is null otherwise return the bool from the TryGetValue?

A quick and slightly dirty way is doing:
string thing="";
if(request.Session.Attributes?.TryGetValue("varName", out thing) ?? false)
{
//do stuff
}
In this way you are sure that if Attributes is null, the second branch of the ?? will be chosen and it will not get inside the if.
Personally, I would split it, as having it in a 1-liner does not improve the code that much. It'd become:
string thing="";
var attributes = request.Session.Attributes;
if(attributes != null && attributes.TryGetValue("varName", out thing))
{
//do stuff
}
This is much more readable. Sometimes it is just fair to avoid using new features of the language if they do not improve the code.
Bonus tip:
You can get a line back removing the declaration of things and placing it just after the out 😉:
attributes.TryGetValue("varName", out string thing)

I suspect you're looking for:
if (request.Session.Attributes?.TryGetValue("varName", out thing) == true)
Alternatively:
if (request.Session.Attributes?.TryGetValue("varName", out thing) ?? false)
The null-coalescing ?? operator here is effectively saying "If we didn't call TryGetValue because Attributes is null, this is what I want to pretend it returned."

to set a default value of an nullable type in c# you can use the ?? opperator
if(nullableboolean ?? false){
}
so that would default to false

Something like this:
Dictionary<string,string> stuff = null;
if(stuff?.TryGetValue("key",out string val) ?? false){
Console.WriteLine("hey");
}

What is the common way to cast non-nullable or return default(Type)

Working with all the dictionaries within ASP.NET MVC (like RouteData, DataTokens etc), I often find myself wanting to do stuff like:
bool isLolCat = routeData["isLolcat"] as bool
that would return the casted value, or default (false in this case) when the value is null.
Is there any short, readable, simple way to do this, or am I better off writing a helper extension method?
An extension method would something like this.
bool isLolCat = routeData["isLolcat"].TryCast<bool>();
I rather don't want to reinvent the wheel with custom syntax if there is a common way to do this.
I don't want to litter my code with a few lines, when I just to try to get a bool out of a dictionary.

Maybe you like any of these:
(routeData["isLolcat"] as bool?).GetValueOrDefault()
(routeData["isLolcat"] as bool?).GetValueOrDefault(false)
(routeData["isLolcat"] as bool?) ?? false
If not you'll have to write a helper. I actually recommend using a helper because the code that I posted kind of obfuscates what you mean. I'd rather see this:
routeData.GetOrDefault<bool>("isLolcat")
Because this documents in writing what you intend.

Is there any short, readable, simple way to do this, or am I better off writing a helper extension method?
I'd say you would be better writing your own extension because you can make your intentions clear
public static class Ext
{
public static T CastOrDefault<T>(this object obj)
{
return obj is T ? (T)obj : default(T);
}
}
...
bool isLolCat = RouteData["isLolCat"].CastOrDefault<bool>();
Suggestion - If you wanted to keep it short, you could call it something like As<T>
bool isLolCat = RouteData["isLolCat"].As<bool>();
string str = RouteData["isLolCat"].As<string>(); // null

I don't think there's a most common way, all casting / conversion operations have their own idiosyncrasies.
For example, Convert.ToBool can accept strings to convert, do you want this to convert, or should this fail?
x as bool will give you null if it's not of type bool.
I think it would be best to write an extension method for RouteData.
public static T GetValueOrDefault<T>(this RouteData routeData, string field)
{
var value = routeData[field];
if (value is T)
{
return (T)value;
}
return default(T);
}
This way you're operating on the RouteData class and not potentially null values.
Usage:
var isLolCat = routeData.GetValueOrDefault<bool>("IsLolCat");

Handling null in extension method

I have a simple extension method for string class which will strip all non numeric characters from a string. So if I have a string like for example a phone number such as "(555) 215-4444" it will convert it to "5552154444". It looks like this:
public static string ToDigitsOnly(this string input)
{
Regex digitsOnly = new Regex(#"[^\d]");
return digitsOnly.Replace(input, String.Empty);
}
I am just wondering what is the most elegant way to handle a null value here? Is there a typical pattern to follow in these cases, such as return back a null value if a null is passed in? It seems since I'm extending the string class here I may want to allow null values and not throw a arguement exception (since I'm not really passing in an arguement when I use this...) ? But some might argue I should throw an exception like a 'normal' method would. What's the best practice you are using here?
Thanks!

You can follow the principle of least surprise: use pattern implemented in LINQ:
public static string ToDigitsOnly(this string input)
{
if(input == null)
throw new ArgumentNullException("input");
Regex digitsOnly = new Regex(#"[^\d]");
return digitsOnly.Replace(input, String.Empty);
}
You can use method, proposed by Jon Skeet. It will reduce your check simply to
input.ThrowIfNull("input");
Also Jon has a good section 10.2.4 Calling a method on a null reference in C# in Depth, quote:
CHECKING FOR NULLITY As a conscientious developer, I’m sure that your
production methods always check their arguments’ validity before
proceeding. One question that naturally arises from this quirky
feature of extension methods is what exception to throw when the first
argument is null (assuming it’s not meant to be). Should it be
ArgumentNullException, as if it were a normal argument, or should it
be NullReferenceException, which is what would’ve happened if the
extension method had been an instance method to start with? I
recommend the former: it’s still an argument, even if the extension
method syntax doesn’t make that obvious.
I see this recommendation as (and from my personal experience): it's always better to check for null, specially for static methods and do not to rely on null values. One exception only if it is the exact purpose of your method, for example ThrowIfNull or IsNullOrEmpty extension methods.

It doesn't really matter as long as you communicate the behavior well (so that the end-user knows what to expect).
Consider using the built-in XML Documentation Comments to communicate expected behavior.
/// <exception cref="ArgumentNullException">argument is null.</exception>
public string Example( string argument )
{
if ( argument == null )
throw new ArgumentNullException();
return argument.ToString();
}
See MSDN documentation for many examples:
DateTime.ParseExact Method (String, String, IFormatProvider)
Uri.FromHex Method

Suppose I have this:
class A
{
public void F()
{
//do stuff
}
}
If I then run the following code, what happens?
A a = null;
a.F();
You get a NullReferenceException. So I would say the proper way to write an equivalent extension method would be as follows.
class A
{
}
static class AExtensions
{
void F(this A a)
{
if (a == null)
{
throw new NullReferenceException();
}
//do stuff
}
}
However, .NET disagrees with me on this. The standard in .NET is to instead throw an ArgumentException - so it's probably best to do that instead.

Simple ; Create another method for String , say IsInValid()
public static bool IsInValid(this string s)
{
return (s == null) || (s.Length == 0);
}
use whereever you wanna check...
Furthermore, you can use this extension anywhere

Is there any reason to use this Regex method over String.IsNullOrEmpty()?

I have a method called isStringOnlyWhitespace():
public static bool isStringOnlyWhitespace(string toEval)
{
string stringNoWhitespace = Regex.Replace(toEval, #"\s", "");
if (stringNoWhitespace.Length > 0) return false;
else return true;
}
Is there any reason to use this method to check for blank/null strings over String.IsNullOrEmpty()?

Sure, if you are shooting for slower code that is harder to read :)
You really want to use string.IsNullOrWhitespace though. Whoever wrote that code might have done so before this method existed. But even still, I'd prefer myString.Trim().Length == 0 in that case.

The method you give doesn't handle nulls whereas String.IsNullOrEmpty does.
That would indicate to me that passing your method a null value is an error condition which is different behavior from String.IsNullOrEmpty.
Also, as others have pointed out, your method would return true for isStringOnlyWhitespace(" ") whereas String.IsNullOrEmpty(" ") would return false.

Yes. Strings containing only whitespace are not considered to be empty. isStringOnlyWhitespace(" ") returns true, but string.IsNullOrEmpty(" ") returns false.

No ;)
a) I think since .net 4 you can use string.IsNullOrWhitespace
b) try something like
public static bool IsStringOnlyWhitespace(this string str)
{
// if you want to check for null:
return str == null || string.IsNullOrEmpty(str.Trim());
// else
return string.IsNullOrEmpty(string.Trim());
}

Evil use of Maybe monad and extension methods in C#?

edit 2015 This question and its answers are no longer relevant. It was asked before the advent of C# 6, which has the null propagating opertor (?.), which obviates the hacky-workarounds discussed in this question and subsequent answers. As of 2015, in C# you should now use Form.ActiveForm?.ActiveControl?.Name.
I've been thinking about the null propagation problem in .NET, which often leads to ugly, repeated code like this:
Attempt #1 usual code:
string activeControlName = null;
var activeForm = Form.ActiveForm;
if (activeForm != null)
{
var activeControl = activeForm.ActiveControl;
if(activeControl != null)
{
activeControlname = activeControl.Name;
}
}
There have been a few discussions on StackOverflow about a Maybe<T> monad, or using some kind of "if not null" extension method:
Attempt #2, extension method:
// Usage:
var activeControlName = Form.ActiveForm
.IfNotNull(form => form.ActiveControl)
.IfNotNull(control => control.Name);
// Definition:
public static TReturn IfNotNull<TReturn, T>(T instance, Func<T, TReturn> getter)
where T : class
{
if (instance != null ) return getter(instance);
return null;
}
I think this is better, however, there's a bit of syntactic messy-ness with the repeated "IfNotNull" and the lambdas. I'm now considering this design:
Attempt #3, Maybe<T> with extension method
// Usage:
var activeControlName = (from window in Form.ActiveForm.Maybe()
from control in window.ActiveControl.Maybe()
select control.Name).FirstOrDefault();
// Definition:
public struct Maybe<T> : IEnumerable<T>
where T : class
{
private readonly T instance;
public Maybe(T instance)
{
this.instance = instance;
}
public T Value
{
get { return instance; }
}
public IEnumerator<T> GetEnumerator()
{
return Enumerable.Repeat(instance, instance == null ? 0 : 1).GetEnumerator();
}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return this.GetEnumerator();
}
}
public static class MaybeExtensions
{
public static Maybe<T> Maybe<T>(this T instance)
where T : class
{
return new Maybe<T>(instance);
}
}
My question is: is this an evil abuse of extension methods? Is it better than the old usual null checks?

It's interesting that so many people independently pick the name IfNotNull, for this in C# - it must be the most sensible name possible! :)
Earliest one I've found on SO: Possible pitfalls of using this (extension method based) shorthand
My one (in ignorance of the above): Pipe forwards in C#
Another more recent example: How to check for nulls in a deep lambda expression?
There are a couple of reasons why the IfNotNull extension method may be unpopular.
Some people are adamant that an extension method should throw an exception if its this parameter is null. I disagree if the method name makes it clear.
Extensions that apply too broadly will tend to clutter up the auto-completion menu. This can be avoided by proper use of namespaces so they don't annoy people who don't want them, however.
I've played around with the IEnumerable approach also, just as an experiment to see how many things I could twist to fit the Linq keywords, but I think the end result is less readable than either the IfNotNull chaining or the raw imperative code.
I've ended up with a simple self-contained Maybe class with one static method (not an extension method) and that works very nicely for me. But then, I work with a small team, and my next most senior colleague is interested in functional programming and lambdas and so on, so he isn't put off by it.

Much as I'm a fan of extension methods, I don't think this is really helpful. You've still got the repetition of the expressions (in the monadic version), and it just means that you've got to explain Maybe to everyone. The added learning curve doesn't seem to have enough benefit in this case.
The IfNotNull version at least manages to avoid the repetition, but I think it's still just a bit too longwinded without actually being clearer.
Maybe one day we'll get a null-safe dereferencing operator...
Just as an aside, my favourite semi-evil extension method is:
public static void ThrowIfNull<T>(this T value, string name) where T : class
{
if (value == null)
{
throw new ArgumentNullException(name);
}
}
That lets you turn this:
void Foo(string x, string y)
{
if (x == null)
{
throw new ArgumentNullException(nameof(x));
}
if (y == null)
{
throw new ArgumentNullException(nameof(y));
}
...
}
into:
void Foo(string x, string y)
{
x.ThrowIfNull(nameof(x));
y.ThrowIfNull(nameof(y));
...
}
There's still the nasty repetition of the parameter name, but at least it's tidier. Of course, in .NET 4.0 I'd use Code Contracts, which is what I'm meant to be writing about right now... Stack Overflow is great work avoidance ;)

If you want an extension method to reduce the nested if's like you have, you might try something like this:
public static object GetProperty(this object o, Type t, string p)
{
if (o != null)
{
PropertyInfo pi = t.GetProperty(p);
if (pi != null)
{
return pi.GetValue(o, null);
}
return null;
}
return null;
}
so in your code you'd just do:
string activeControlName = (Form.ActiveForm as object)
.GetProperty(typeof(Form),"ActiveControl")
.GetProperty(typeof(Control),"Name");
I don't know if I'd want to use it to often due to the slowness of reflection, and I don't really think this much better than the alternative, but it should work, regardless of whether you hit a null along the way...
(Note: I might've gotten those types mixed up) :)

In case you're dealing with C# 6.0/VS 2015 and above, they now have a built-in solution for null propagation:
string ans = nullableString?.Length.ToString(); // null if nullableString == null, otherwise the number of characters as a string.

The initial sample works and is the easiest to read at a glance. Is there really a need to improve on that?

The IfNotNull solution is the best (until the C# team gives us a null-safe dereferencing operator, that is).

I'm not too crazy about either solution. What was wrong with ashorter version of the original:
string activeControlName = null;
if (Form.ActiveForm != null)
if (Form.ActiveForm.ActivControl != null) activeControlname = activeControl.Name;
If not this, then I would look at writing a NotNullChain or FluentNotNull object than can chain a few not null tests in a row. I agree that the IfNotNull extension method acting on a null seems a little weird - even though extension methods are just syntactic sugar.
I think Mark Synowiec's answer might be able to made generic.
IMHO, I think the C# core team should look at the this "issue", although I think there are bigger things to tackle.

Sure, original 2-nested IF is much more readable than other choices. But suggesting you want to solve problem more generally, here is another solution:
try
{
var activeForm = Form.ActiveForm; assumeIsNotNull(activeForm);
var activeControl = activeForm.ActiveControl; assumeIsNotNull(activeControl);
var activeControlname = activeControl.Name;
}
catch (AssumptionChainFailed)
{
}
where
class AssumptionChainFailed : Exception { }
void assumeIsNotNull(object obj)
{
if (obj == null) throw new AssumptionChainFailed();
}