C#6: Null-conditional operators

With the release of Visual Studio 2015 in July came C# 6. Each iteration of C# has tended to have a theme and if there were a theme for this one, it would be developer productivity; all the new features in C# 6 appear to be either improvements to existing features, or syntactical shortcuts to simplify common operations. One of those syntactical shortcuts is the `?.` operator1, which is accompanied by the similar `?[]` operator2.

These new operators are collectively known as null-conditional operators. Most, if not all C# developers have used the null-coalescing operator, `??` and found it to be brilliant…until the next step was to call a method or property on the result. Though `(something ?? somethingelse).Property` seems like it might be a good idea, there is rarely a suitable `somethingelse` that doesn't just feel like hack, so invariably, we resort to an `if` or the conditional operator, `?:`3.

var x = new MyClass();

ReturnTypeOfDoSomethingCool y = null;
if (x != null)
{
    y = x.DoSomethingCool();
}

// or, perhaps,

var y = x == null ?4;

In C# 6, the `?.` and `?[]` operators step up to help. These new null-conditional operators check the value on the left of the operator and, if it is null, return null, short-circuiting the remainder of the expression; if the value on the left of the operator is non-null, the expression continues according to precedence rules.

Using these operators, we can express our earlier code much more succinctly and without resorting to convoluted, hacky `??` chains.

var x = new MyClass();
var y = x?.DoSomethingCool();

// and, with an indexer,

var a = new List<int>();
Console.WriteLine( a?[0] ?? "nothing" );

There isn't much else to write about these simple operators except to draw attention to how `?.` works with `Nullable<T>` types such as `int?`5. Consider the `??` operator. When the `??` operator is applied to a nullable type like `int?`, it either returns the value wrapped in that `int?` or the value evaluated from the right of the operator. That is to say that instead of needing to reference the `Value` property of the nullable directly, the operator does that for you. The following assignment works because `x.Value` is returned from the `??` operator, not `x`.

int? x = 10;
int y = x ?? 0;

The `?.` operator works the same way, which means the following does not make sense and won't compile; `Value` is not a property of `int`:

int? x = 10;
int y = x?.Value;

Whereas this will work just fine:

int? x = 10;
string y = x?.ToString();

In Conclusion…

The null-conditional operators, `?.` and `?[]` provide some shortcuts that will no doubt lead to clearer code, and I welcome their addition to the C# language. I hope that you do to.

 

  1. aka, the one-eyed Elvis operator []
  2. the robot Elvis, or Howard The Duck []
  3. The two-eyed Elvis []
  4. ReturnTypeOfDoSomethingCool)null) : x.DoSomethingCool();

    Or, if using an indexer:

    var x = new List<int>();
    if (x != null)
    {
       Console.WriteLine(x[0]);
    }
    
    Console.WriteLine(x == null ? "nothing" : x[0].ToString( []
  5. also expressible as `Nullable<int>` []

Tracepoints, Conditional Breakpoints, and Function Breakpoints

We've all been there: we step through our code with breakpoints and it works just fine, but run it without ever hitting a breakpoint and our code explodes in a fiery ball of enigmatic failure. Perhaps the failure only happens after the 1000th call of a method, when a variable is set to a specific value, or the value of a variable changes. These bugs can be hard to investigate without actually modifying the software that has the bug, which then means you are no longer debugging the same software that had the bug and might mean the bug disappears1.

Thankfully, Visual Studio has our backs on tracking down some of these more obscure bugs. Visual Studio allows us to modify our breakpoints to only break on certain conditions (like the 5th loop iteration, or when a file is open), to output text to the debug window, or to just output text and not actually break into our code. We can even create breakpoints that break on any function that matches a name we provide, just in case you don't even know which code it's actually calling.

Though I discuss the 2015 experience, the features themselves have been around for quite some time. I would not be surprised if this were the first time you had heard about these breakpoint settings, they have always been somewhat hidden away from the primary workflow. Even now, with the updated user experience, they are not obvious unless you go exploring.  If you want to see how to use them in your variant of Visual Studio, or get more information on breakpoints in 2015, MSDN has you covered (2003|2005|2008|2010|2012|2013|2015).

Conditions and Actions

Floating breakpoint toolbar

Let's begin by taking a look at adding conditions and tracepoints. When you add a breakpoint to a line of code, either by using the F9 keyboard shortcut or left-clicking in the code margin, a little toolbar appears to the upper right of the cursor2 . The toolbar has two icons: the first is called Settings…, where all the cool stuff lives; the second is called Disable Breakpoint, which is very useful if you have customized the breakpoint3. If you click the Settings… button, you will see an inline dialog with two checkboxes; Conditions and Actions4.

If you check the first box, Conditions, you will be presented with various fields for specifying a condition under which the breakpoint fires. There are three types of condition;

  1. Conditional Expression
  2. Hit Count
  3. Filter
Adding a condition to a breakpoint
Adding a condition to a breakpoint

Conditional Expression conditions allow you to specify a condition based on variables within your code. You can break on when a specific condition is met, or when a condition changes (this allows you to break when a variable changes value, for example).

Hit Count conditions allow you to break once after the breakpoint has been hit a specific number of times (such as on the fifth index of an array in a loop), every time after the breakpoint has been hit a specific number of times, or every time the hit count is a multiple of a specific number (like every other hit, or once every five hits).

Filter conditions allow you to specify filters based on process, thread, and machine names, and process and thread identifiers.

Conditional breakpointYou can add multiple conditions to a breakpoint, which all have to match for the breakpoint to fire. When a condition is applied to a breakpoint, the red circle will have a white plus symbol inside it.

Adding output text to a breakpoint
Adding output text to a breakpoint

If you check the Actions box, you can specify text to be outputted when the breakpoint fires. By default, a checkbox named Continue Execution will be checked because, usually, if specifying output text, you want a tracepoint rather than a breakpoint. However, if you want to break and output text, you can uncheck this additional checkbox.

Non-breaking breakpoint (aka tracepoint)When a breakpoint is set to continue execution, the red circle changes into a red diamond. If a condition is also applied, the diamond has a white cross Conditional non-breaking breakpoint (aka tracepoint)in it.

If you use the Oz-code extension for Visual Studio, tracepoints are given some additional support with a quick action to add a tracepoint and a tracepoint viewer that shows you just tracepoints.

Function Breakpoints

Adding a function breakpoint
Adding a function breakpoint

So far, we've looked at traditional breakpoints that are set on specific lines of code. Function breakpoints are set against function names. To add a function point, use the Visual Studio menu to go to Debug→New Breakpoint→Function Breakpoint…5. Selecting this will show a dialog where you can specify the function name (qualifying it as you require), and the language to which the breakpoint applies. You can also specify conditions and actions as with any other breakpoint.

In Conclusion…

Visual Studio is a complex development environment, which unfortunately leads to some of its cooler features being harder to find. I hope you find this introduction to breakpoint superpowers useful, if you do or if you have more Visual Studio debugging tips, I'd love to hear from you in the comments.

Today's featured image is "Debugging the Computer" by Jitze Couperus. The image is licensed under CC BY 2.0. Other than being resized, the image has not been modified.

  1. yay, fixed it… []
  2. This also appears if you hover over an existing breakpoint in the margin []
  3. Deleting the breakpoint would also delete any customization, but disabling does not []
  4. This dialog can also be reached by right-clicking the breakpoint and choosing either Conditions… or Actions… or by hitting Alt+F9, C; the only difference here is that one of the two checkboxes will get checked automatically []
  5. You can also add one via the keyboard with Alt+F9, B or the New… dropdown in the Breakpoints tool window []