nameof expression

by ArlenPosted on July 21, 2015 Posted in Programming — No Comments ↓

This is one of a series of posts on some of the new features in C# 6.0, which was just released.

In C# there is a very handy expression – typeof – that returns the Type of an object. For example:

if(someObject.GetType() == typeof(MyClass))
  DoSomething(someObject);

(Not very OO, but there are times when it is really helpful).

C# 6 adds a similar operator – nameof – which returns the name of an object:

Console.WriteLine("The variable name is " + nameof(someObject));

>>The variable name is someObject

Although there aren’t a ton of situations where this is needed, it is really helpful when dealing with things like logging and exceptions. For example:

private void DoSomething(Customer cust)
{
  if(cust == null)
    throw new ArgumentNullException(nameof(cust));
}

Of course, you could always explicitly provide the name, but if you rename the argument, it is very easy to forget to update a constant string. This could also be used when dealing with raising events, a la WPF, where you want to fire a changed event for a specific property.

Note that even if the object is fully qualified, only the name itself will be returned:

Console.WriteLine("The variable name is " + 
    nameof(SomeClass.SomeProperty));

>>The variable name is SomeProperty

Here are links to posts about other new features in C# 6.0:

• Null-conditional operators
• Auto-property initializers
• using static
• Expression bodies on properties and methods
• Exception filters
• String interpolation
• nameof expression
• Index initializers

String interpolation

by ArlenPosted on July 21, 2015 Posted in Programming — No Comments ↓

This is one of a series of posts on some of the new features in C# 6.0, which was just released.

The ability to format strings in .NET is straightforward, and fairly powerful (ignore the line breaks):

string value = string.Format("My name is {0}, and I was born in 
    {1:yyyy}", ob.Name, ob.Birthday);

Note that you can have multiple arguments, and you can add various formatting options to control the display. One downside with this approach, however, is that it is easy to mess up — when you add, remove or change the arguments, the various placeholders might not line up correctly, which can give you bad strings or possibly an exception.

String interpolation fixes this by letting you specify values in place within a string. To do this, you prefix the string with a dollar sign, then put your specific arguments in place:

string value = $"My name is {ob.Name}, and I was born in {ob.Birthday}";

You can even add formatting:

string value = $"My name is {ob.Name}, and I was born in 
    {ob.Birthday:yyyy}";

This will return the same value as the original string.Format example above. You can also add logic:

string value = $"My name is 
    {(!string.IsNullOrWhiteSpace(p.Name) ? p.Name : "Unknown")}, 
    and I was born in {ob.Birthday:yyyy}";

(You generally have to put parens around the logic to avoid confusing the parser).

This is a very cool feature, and I can see it being used when logging or building strings for internal use. The one place I probably won’t use it is in any place where I am building strings that are shown to the user–largely because I generally build localizable applications, so all of my user-visible strings will end up in resource files. There is no way to use string interpolation with resource files (which is probably a good thing, since otherwise localizers could really mess up your applications).

So I think this feature will be useful-ish, but somewhat limited.

Here are links to posts about other new features in C# 6.0:

• Null-conditional operators
• Auto-property initializers
• using static
• Expression bodies on properties and methods
• Exception filters
• String interpolation
• nameof expression
• Index initializers

Exception filters

by ArlenPosted on July 21, 2015 Posted in Programming — No Comments ↓

This is one of a series of posts on some of the new features in C# 6.0, which was just released.

When catching exceptions in code, you can have a different catch block for different types of exceptions:

try
{
}
catch(SqlException ex)
{
  // Do something
}
catch(Exception ex)
{
  // Log error
}

But if you want to handle exceptions differently depending on the details of the exception, you could not until now — you would have to build the logic into the block:

try
{
}
catch(SqlException ex)
{
  if(ex.Number == 2627)
  {
    // Handle primary key violation
  }
  else
  {
    // Do exactly the same thing as the main exception block
  }
}
catch(Exception ex)
{
  // Log error
}

Now, though, you can add conditions to your catch block:

try
{
}
catch(SqlException ex) when (ex.Number == 2627)
{
    // Handle primary key violation
}
catch(Exception ex)
{
  // Log error
}

Now, the first catch block will only get called if the specific error is handled. You could equally have multiple catches for the same type of exception, but with different details:

try
{
}
catch(SqlException ex) when (ex.Number == 2627)
{
    // Handle primary key violation
}
catch(SqlException ex) when (ex.Number == 2601)
{
    // Handle unique index exception
}
catch(SqlException ex)
{
   // Handle other SQL Exception
}
catch(Exception ex)
{
  // Log error
}

This not only makes code cleaner in general, it also avoids duplicate code in different blocks (duplicate code is very high up in my list of coding sins).

Note that you can also have more complex logic in the condition, and can call methods:

catch(SqlException ex) when (ex.Number == 2627 || ex.Number == 2601)

or

catch(SqlException ex) when (IsAConstraintViolation(ex.Number))

Which leads to an interesting semi-evil trick – since you can call a method, that method can do something with the exception, then return false, meaning that you are responding to the exception, but not catching it. For example, you could log the specific exception, but then let handling fall through to the next exception handler:

try
{
}
catch(SqlException ex) when (LogSqlException(ex))
{
}
catch(Exception ex)
{
  // Standard exception handling here
}

Of course, LogSqlException() would have to return false. I think that logging-type operations are the only acceptable things to handle in this way since this would otherwise generate a maintenance nightmare. I suspect, though, that we will see some interesting uses of this…

Here are links to posts about other new features in C# 6.0:

• Null-conditional operators
• Auto-property initializers
• using static
• Expression bodies on properties and methods
• Exception filters
• String interpolation
• nameof expression
• Index initializers

Expression bodies on properties and methods

by ArlenPosted on July 21, 2015 Posted in Programming — No Comments ↓

This is one of a series of posts on some of the new features in C# 6.0, which was just released.

Expression bodies let you use lambda-style expression declarations for methods and properties. So, instead of:

public int Add(int x, int y) { return x + y; }
public static Rectangle CreateSquare(int left, int top, int size) 
{
  return new Rectangle(left, top, size, size);
}

public string Address
{
  get { return City + ", " + State + "  " + Zip; }
}

You can instead write:

public int Add(int x, int y) => x + y;
public static Rectangle CreateSquare(int left, int top, int size)
     => new Rectangle(left, top, size, size);

public string Address2 => City + ", " + State + "  " + Zip;

Note that, for the property, you don’t have to explicitly specify “get” since it is implied — and you can’t have a “set”.

For methods, I think that this is probably a bad idea, and I would avoid using it — you otherwise end up with two completely different formats for doing something with very little compelling advantage.

For properties, I am slightly less bothered, since it is a lot more compact (and in general I think that more compact code for simple operations is easier to read), but if the logic becomes complex (as lambdas have a habit of doing) then I would probably revert back to the more explicit format.

By the way, you can also use this syntax for indexers:

public Shape this[int index] => myList[index];

Here are links to posts about other new features in C# 6.0:

• Null-conditional operators
• Auto-property initializers
• using static
• Expression bodies on properties and methods
• Exception filters
• String interpolation
• nameof expression
• Index initializers

The “using static” statement

by ArlenPosted on July 21, 2015 Posted in Programming — No Comments ↓

This is one of a series of posts on some of the new features in C# 6.0, which was just released. I had to be careful about naming this one because just calling it “using static” implies a different topic!

The using static is a new type of “using” statement that you can put at the top of your file declaration, but instead of referencing a namespace, you reference a specific class or enum:

using static System.Console;

This allows you to reference the static members of the class directly without including the class name:

public void SomeMethod()
{
  WriteLine("Twas Brilig");
  ReadLine("");
}

instead of

public void SomeMethod()
{
  Console.WriteLine("Twas Brillig and the slithy toves...");
  Console.ReadLine("");
}

Although, of course, you may have conflicts if you include multiple classes.

I think that this is one of those things that can be useful if used judiciously, but has the opportunity for confusion if overused.

Here are links to posts about other new features in C# 6.0:

• Null-conditional operators
• Auto-property initializers
• using static
• Expression bodies on properties and methods
• Exception filters
• String interpolation
• nameof expression
• Index initializers

Auto-property initializers

by ArlenPosted on July 20, 2015 Posted in Programming — No Comments ↓

This is one of a series of posts on some of the new features in C# 6.0, which was just released.

Auto-properties were added some time ago. An auto-property lets you define a property without a backing field:

public string MyProperty {get; set;}

While these are extremely useful, if you want to initialize the properties, you generally have to do it in your constructor(s) which might be some way away from your property declaration:

public class MyClass 
{
  public MyClass()
  {
    MyProperty = "Doom";
  }

  public string MyProperty {get; set;}
}

When you have a backing field, the backing field could be initialized at the declaration:

private myField = "Doom";

Well, now you can do the same thing with auto-properties:

public string MyProperty {get; set;} = "Doom";

This keeps the value next to the property, which makes it easier to manage. You can also now create read-only properties that are initialized in the same way:

public string MyProperty {get;} = "Doom";

This isn’t that useful if you are using a constant string (since you could just as easily use a const), but if the value is initialized in a more complex way, this becomes more useful:

public string MyProperty {get;} = GetInitialValue();

Note that GetInitialValue() will have to be a static method – you can’t access instance methods because the class is not yet fully initialized.

Here are links to posts about other new features in C# 6.0:

• Null-conditional operators
• Auto-property initializers
• using static
• Expression bodies on properties and methods
• Exception filters
• String interpolation
• nameof expression
• Index initializers

Null-conditional operator

by ArlenPosted on July 20, 2015 Posted in Programming — No Comments ↓

This is one of a series of posts on some of the new features in C# 6.0, which was just released.

Null-conditional member access is a great new feature that, I think, will help make code more bullet-proof and easier to read.

How often have you seen code like this:

MyResult mr = null;
if(ob != null)
{
  MyClass mc = ob.SomeMethod();
  if(mc != null)
  {
    MyClass2 mc2 = mc.SomeOtherMethod();
    if(mc2 != null)
      mr = mc2.SomeThirdMethod();
  }
}

or, worse:

 MyResult mr = ob.SomeMethod().SomeOtherMethod().SomeThirdMethod();

with absolutely no null checks at all. A common trick is to use the ternary operator:

MyClass mc = (ob != null) ? ob.SomeMethod() : null;
MyClass2 mc2 = (mc != null) ? mc.SomeOtherMethod() : null;
MyResult mr = (mc2 != null) ? mc2.SomeThirdMethod() : null;

which is better, but still somewhat verbose. Enter null-conditional operators:

MyResult mr = ob?.SomeMethod()?.SomeOtherMethod()?.SomeThirdMethod();

The ?. can be read as “If the thing on the left is not null, then call the thing on the right. Otherwise, just return null and stop processing.”

To be fair, I think that it is probably not a great idea to create huge chains of code using this, but used in moderation, I think that it a) makes code easier to read and b) encourages coders to actually do a null check, since it is quicker, and less verbose.

Note that this also works with indexers:

string name = myList?[1]?.Name;

This will short circuit if myList is null or if the item at position 1 in the array is null. Note, however, that if the list has less than 2 items, you will still get an exception – the code checks for nulls, not bounds.

Another cool use for the null-conditional is when dealing with events. Rather than having to check to see if the event handler is defined, you can just do this:

SomeHandler?.Invoke(this,args);

Which also has the advantage of being thread-safe. It is very common to see code like this:

if(SomeHandler != null)
  SomeHandler(this, args);

Which is fine almost all of the time — except if a different thread happens to unsubscribe to the event sometime between the check and the call. Technically, the correct code would be:

var handler = SomeHandler;
if(handler != null)
  handler(this, args);

I remember early discussions about the C# language where the discussion was whether there needed to be special handling for this to be thread-safe without the extra code. The feeling was that most of the time, this wasn’t enough of a risk to make it worth extending the language, but the null-conditional operator takes care of it now anyway.

Here are links to posts about other new features in C# 6.0:

• Null-conditional operators
• Auto-property initializers
• using static
• Expression bodies on properties and methods
• Exception filters
• String interpolation
• nameof expression
• Index initializers