To step through the recipes in this book, you will need a copy of Visual Studio 2015. If you do not have a copy of Visual Studio 2015, you can download a free copy of Visual Studio 2015 Community from https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx.

You can also compare editions of Visual Studio 2015 by navigating to https://www.visualstudio.com/en-us/products/compare-visual-studio-2015-products-vs.aspx.

After you have downloaded and installed Visual Studio 2015, create a new console application that will contain the recipes illustrated in this book.

This console application will form the base of the recipes in this book. Each recipe can be individually added to this console application. A recipe, therefore, can function on its own without the need to create a previous recipe. You can also easily separate any custom code you might want to add and experiment with. It is also recommended that you play around with the code by adding classes of your own.

Create a new class to test your code. We will use the example of reading the current exchange rate for a specific currency to illustrate how string interpolation can be used to output strings to the user interface.

The console application passes the currency codes for South African Rand and US Dollar to the static class by calling the following line of code: Chapter1.Recipe1StringInterpolation.ReadExchangeRate("ZAR", "USD");

This class is static and, as mentioned previously, does not need to be instantiated. The ReadExchangeRate method then reads the exchange rate and formats it into a suitable string using string interpolation. You will notice that the interpolated string expression is written as $"1 {toCurrencyCode} = {conversion} {fromCurrencyCode} ";.

The toCurrencyCode, conversion, and fromCurrencyCode variables are expressed directly inside the string expression. This is a much easier way of formatting strings because you can do away with String.Format, used in the previous versions of C#. Previously, the same expression would have been written as String.Format("1 {0} = {1} {2} ", toCurrencyCode, conversion, fromCurrencyCode);.

As you can see, the interpolated string expression is much easier to read and write. In reality though, string interpolation is merely syntactical sugar because the compiler treats the expression like String.Format anyway. You might be wondering how you would express a curly bracket when using string interpolation. To do this, you can simply use a double curly bracket in your expression. If you need to express the exchange rate as {16,3040}, you would need to express it as $"{{{conversion}}}";.

You can also format your string right there inside the interpolated string expression. If you returned the $"The date is {DateTime.Now}"; expression, the output would be The date is 2016/01/10 3:04:48 PM. You can go ahead and modify the expression to format the date using a colon, followed by the format to use. Change the code to $"The date is {DateTime.Now : MMMM dd, yyyy}";. The output will be formatted and result in The date is January 5, 2016.

Another great tip is that you can express a condition in the string expression. Consider the following line of code that determines whether a year is a leap year or not:

$"The year {DateTime.Now.Year} {(DateTime.IsLeapYear(DateTime.Now.Year) ? " is " : " is not ")} a leap year.";

We can use the ternary ? operator one step further. Consider the following line of code:

$"There {(StudentCount > 1 ? "are " : "is ")}{StudentCount} student{(StudentCount > 1 ? "s" : "")} in the list."

As the colon is used to denote formatting, we have to wrap the conditional part of the expression in parenthesis. String interpolation is a very nice way to express strings in code that is easy to read and understand.

We will create another class that will illustrate the use of the null-conditional operator. The method will call a Student class to return a count of students in the resulting list. We will check to see whether the Student class is valid before returning the student count.

Consider the code we used in the return statement:

return students?.Count() ?? 0;

We told the compiler to check whether the List<Student> class' variable students is null. We did this by adding ? after the students object. If the students object is not null, we use the dot operator, and the Count() property becomes the result of the statement.

If the students object however is null, then we return zero. This way of checking for null makes all that if(students != null) code unnecessary. The null check sort of fades into the background and makes it much easier to express and read null checks (not to mention less code).

If we had to change the return statement to a regular Count() method without the null-conditional operator, we would see an ArgumentNullException was unhandled error:

return students.Count();

Calling Count() on the students object without using the null-conditional operator breaks the code. The null-conditional operator is an exciting addition to the C# language because it makes writing code to check for null a lot easier. Less code is better code.

To illustrate how to implement these two new enhancements to auto-implemented properties, we will create another class that calculates the sales price after discount for a given barcode and discount type.

If you look at the auto-implemented properties again, you would notice that we have two getter-only auto-implemented properties. All four auto-implemented properties have been initialized with default values. The SaleDiscountPercent and ClearoutDiscountPercent properties are read-only. This ensures that the discount values can't be modified in any way.

You will also notice that if the shelf price returned from the GetPriceFromBarcode method is zero, then the default ShelfPrice property value is used in determining the discount price. If no discount is applied, the CalculateSalePrice method simply returns the barcode price. If no price is determined from the barcode, the default ShelfPrice property value is returned.

Auto-implemented property initializers and getter-only auto-implemented properties are great to cut down on unnecessary if else statements. It also makes the code implementing the properties more readable because the intent can be contained in the property itself by initializing it.

Look at what happens if we try to set the SaleDiscountPercent or ClearoutDiscountPercent property to a different value:

Visual Studio will emit an error for the getter-only properties because using the get keyword, we can only read from this property, not assign a value to it.

The change here is subtle. We will create a method to return the day of the week based on an integer. We will also create a method to return the start of the financial year and salary increase month, and then set the salary increase month to a different value than the default. Finally we will use properties to return a specific type of species to the console window.

The first method ReturnWeekDay created a Dictionary<int, string> object. You can see how the indices are initialized with the day names. If we now pass the day integer to the method, we can return the day name by referencing the index.

In the second example, we called a method called ReturnFinancialAndBonusMonth that creates an array to hold the financial year start month and the salary increase month. Both properties of the Month class are initialized to 2 and 3, respectively. You can see that we are overriding the value of the SalaryIncreaseMonth property and setting it to 2. It is done in the following line of code:

return new List<int>(array) { [1] = 2 };

The last example uses the Human, Rabbit, Sloth, Mouse, Hedgehog, Dolphin, and Dog properties to return the correct index value of the Species object.

We will use the same code example that we wrote in the String interpolation recipe from this chapter, with a few small changes. We will create a Student object and add students to it. We will then return that object to the console and output the student count.

Running the console application with the code as is will call the GetStudents() method. This will then create the List<Student> object and add two Student objects to it. The StudentCount property is set equal to the count of the List<Student> object. The GetStudents() method then returns the result to the console application, which then reads the StudentCount property and displays it in the console output:

If we now went ahead and modified the code in the GetStudents() method to set the students variable to null right before we called students.Count(), an exception would be thrown. The exception is caught in catch, and this is where we use the nameof expression to display a string literal of the students variable:

Using the nameof expression, we can ensure that the expression stays in sync with refactoring actions such as renaming the students variable:

If we had written the code in the catch statement using a string literal, we would not have had the code updated automatically when we renamed the students variable. The nameof expression effectively allowed developers to stop writing throw new ArgumentNullException("students");, which will not be affected by refactoring actions.

Another benefit of using a nameof expression in your code is that it involves no runtime cost, because the code containing the string literal is generated at compile time.

Modify the code in the console application slightly to make it look like this:

List<Chapter1.Student> StudentList = Chapter1.Recipe5NameofExpression.GetStudents();
                
int iStudentCount = Chapter1.Recipe5NameofExpression.StudentCount;
Console.WriteLine($"The value of the { nameof(Chapter1.Recipe5NameofExpression.StudentCount)} property is {iStudentCount}");

When you run your console application now, you can see that the nameof expression has been used to create the string literal of the StudentCount property:

You can also use the nameof expression with enumerators. Add the following code to your class. We are basically creating an enumerator called Course. In the SetCourse() method, we set a course based on a course ID:

public enum Course { InformationTechnology = 1, Statistics = 2, AppliedSciences = 3 }
public static string SelectedCourse { get; set; }
public static void SetCourse(int iCourseID)
{
    Course course = (Course)iCourseID;
    switch (course)
    {
        case Course.InformationTechnology:
            SelectedCourse = nameof(Course.InformationTechnology);
            break;
        case Course.Statistics:
            SelectedCourse = nameof(Course.InformationTechnology);
            break;
        case Course.AppliedSciences:
            SelectedCourse = nameof(Course.InformationTechnology);
            break;
        default:
            SelectedCourse = "InvalidCourse";
           break;
   }            
}

We then use a switch statement to select the course defined by the course ID parameter and set the SelectedCourse property equal to the nameof expression of the enumerator. Add the following code to your console application:

Chapter1.Recipe5NameofExpression.SetCourse(1);
Console.WriteLine($"The selected course is { Chapter1.Recipe5NameofExpression.SelectedCourse}");

Running the console application will result in the string representation of the selected enumerator value:

The nameof expression is a very good way of keeping your code in sync when dealing with the string literals of objects in C# 6.0.

To truly appreciate expression-bodied functions and properties, we need to look at the way code had to be written previously. We will create a class to calculate the sale price of an item, and the class will contain two public methods. One will set a shelf price, and the other will return a message displaying the calculated sale price.

Running your application produces the message displaying the calculated sale price:

Looking back at our class, we can see that it is somewhat bulky. We have a calculated property that returns a sale price and two methods with a single return statement. One sets the shelf price, while the other gets a message containing the sale price. This is where expression-bodied function members come into play. Modify your code in the Recipe6ExpressionBodiedFunctionMembers class to make it look like this:

public static class Recipe6ExpressionBodiedFunctionMembers
{
    private static int SaleDiscountPercent { get; } = 20;
    private static decimal ShelfPrice { get; set; } = 100;

    private static decimal GetCalculatedSalePrice => Math.Round(ShelfPrice.CalculateSalePrice(SaleDiscountPercent));

    public static void SetShelfPrice(decimal shelfPrice) => ShelfPrice = shelfPrice;

    public static string ReturnMessage(string barCode) => $"The sale price for barcode {barCode} is {GetCalculatedSalePrice}";        
}

What we are left with is a terse class that does exactly the same as the code we wrote before. There is less code, it is easier to read, and it looks much cleaner. You will notice the use of the lambda => operator. For the GetCalculatedSalePrice computed property, the get keyword is missing. This became implied when we changed the computed property body to an expression.

One point to remember though is that expression-bodied function members do not work with constructors.

We will create a class called Recipe7UsingStatic that will determine the sale price of an item depending on the day of the week. If it is Friday, we want to apply the sale discount to the item. On any other day, we will sell the item at the shelf price.

Run your console application and see that the sale price is calculated correctly and output to the console application:

Now, let's have a closer look at the code. In particular, look at the GetCalculatedSalePrice computed property. It uses the Math.Round function to round the sale price to two decimals:

private static decimal GetCalculatedSalePrice
{
    get { return Math.Round(ShelfPrice.CalculateSalePrice (SaleDiscountPercent), 2); }
}

The Math class is in reality a static class that contains a collection of functions that you can use throughout your code to perform different mathematical calculations. So, go ahead and add the following using statement at the top of your Recipes.cs file:

using static System.Math;

We can now change our computed GetCalculatedSalePrice property to omit the Math class name:

private static decimal GetCalculatedSalePrice
{
    get { return Round(ShelfPrice.CalculateSalePrice(SaleDiscountPercent), 2); }
}

This is really a fantastic enhancement. Look at the following lines of code:

Math.Sqrt(64);
Math.Tan(64);
Math.Pow(8, 2);

Because of this enhancement, the preceding lines of code can simply be written as follows:

Sqrt(64);
Tan(64);
Pow(8, 2);

There is, however, more to using the static keyword's functionality. We are using static classes for all the recipes in this chapter. We can, therefore, also implement the using static statement for our own custom static classes. Add the following using statements to the top of the console application's Program class:

using static Chapter1.Recipe7UsingStatic;
using static Chapter1.Recipe7UsingStatic.TheDayOfWeek;
using static System.Console;

You will notice that we have included the enumerator in the using static statements. This is equally fantastic, because Friday is clearly a day of the week, and the enumerator doesn't need to be called fully, as in the old console application code. By adding the using static statements, the code in our console application can be changed as follows:

TheDayOfWeek weekday = Friday;
SetShelfPrice(ShelfPrice);
WriteLine(GetSalePrice(weekday));
Read();

This is where the real benefit of the using static statements become evident. It means less code and makes your code more readable. To recap the idea behind C# 6.0, it didn't introduce big new concepts but many small features to make your code cleaner and your intent easier to understand. The using static feature does exactly this.

We will create a new class called Recipe8ExceptionFilters and call a method that reads an XML file. The file read logic is determined by a Boolean flag being set to true. Imagine here that there is some other database flag that when set, also sets our Boolean flag to true, and thus, our application knows to read the given XML file.

If we had to run our application now, we would obviously receive an error (this is assuming that you actually don't have a file called XMLFile.xml in your temp folder). Visual Studio will break on the throw statement:

The Log(ex) method has logged the exception, but have a look at the Watch1 window. We have no idea what the value of blnReadFileFlag is. When an exception is caught, the stack is unwound (adding overhead to your code) to whatever the actual catch block is. Therefore, the state of the stack before the exception happened is lost. Modify your ReadXMLFile and Log methods as follows to include an exception filter:

public static void ReadXMLFile(string fileName)
{
    try
    {
        bool blnReadFileFlag = true;
        if (blnReadFileFlag)
        {
            File.ReadAllLines(fileName);
        }
    }
    catch (Exception ex) when (Log(ex))
    {

    }
}

private static bool Log(Exception e)
{
    /* Log the error */
    return false;
}

When you run your console application again, Visual Studio will break on the actual line of code that caused the exception:

More importantly, the value of blnReadFileFlag is still in scope. This is because exception filters can see the state of the stack at the point where the exception occurred instead of where the exception was handled. Looking at the Locals window in Visual Studio, you will see that the variables are still in scope at the point where the exception occurred:

Imagine being able to view the exception information in a log file with all the local variable values available. Another interesting point to note is the return false statement in the Log(ex) method. Using this method to log the error and return false will allow the application to continue and have the exception handled elsewhere. As you know, catching Exception ex will catch everything. By returning false, the exception filter doesn't run into the catch statement, and more specific catch exceptions (for example, catch (FileNotFoundException ex) after our catch (Exception ex) statement) can be used to handle specific errors. Normally, when catching exceptions, FileNotFoundException will never be caught in the following code example:

catch (Exception ex) 
{

}
catch (FileNotFoundException ex)
{

}

This is because the order of the exceptions being caught is wrong. Traditionally, developers must catch exceptions in their order of specificity, which means that FileNotFoundException is more specific than Exception and must therefore be placed before catch (Exception ex). With exception filters that call a false returning method, we can inspect and log an exception accurately:

catch (Exception ex) when (Log(ex))
{

}
catch (FileNotFoundException ex)
{

}

The preceding code will catch all exceptions, and in doing so log the exception accurately but not step into the exception handler because the Log(ex) method returns false.

Another implementation of exception filters is that they can allow developers to retry code in the event of a failure. You might not specifically want to catch the first exception, but implement a type of timeout element to your method. When the error counter has reached the maximum iterations, you can catch and handle the exception. You can see an example of catching an exception based on a try clauses' count here:

public static void TryReadXMLFile(string fileName)
{
    bool blnFileRead = false;
    do
    {
        int iTryCount = 0;
        try
        {
            bool blnReadFileFlag = true;
            if (blnReadFileFlag)                    
                File.ReadAllLines(fileName);                    
        }
        catch (Exception ex) when (RetryRead(ex, iTryCount++) == true)
        {
                    
        }                
    } while (!blnFileRead);
}

private static bool RetryRead(Exception e, int tryCount)
{
    bool blnThrowEx = tryCount <= 10 ? blnThrowEx = false : blnThrowEx = true;
    /* Log the error if blnThrowEx = false */
    return blnThrowEx;
}

Exception filtering is a very useful and extremely powerful way to handle exceptions in your code. The behind-the-scenes workings of exception filters are not as immediately obvious as one might imagine, but here lies the actual power of exception filters.

We will create another class that will simulate the deletion of a file. An exception is thrown, and the catch block is then executed along with the finally statement. In both the catch and finally clauses, we will delay and await a task for 3 seconds. Then, we will output this delay to the console application window.

After adding the code, run the console application and have a look at the output:

You will notice that the exception thrown was a "file not found" exception. In catch, the code stopped for 3 seconds while the task was delayed. The same is evident for the code in the finally clause. It too was delayed for 3 seconds while the task was delayed.

This means that now, in your C# 6.0 applications, you can, for example, await in the catch clause while an exception log message is written to the log. You can do the same thing in the finally clause while closing database connections to dispose of other objects.

The process of how the compiler does this is rather complicated. You, however, don't need to worry about how this functionality is achieved. All you need to do is know that the await keyword is now available to you as a developer for use in the catch and finally blocks.