C#7: Throw Expressions and More Expression-bodied Members

In this installment of my look at C#7, we will take a look at some nice syntactical enhancements, including the first ever community contribution to the C# language implementation. Before we get started, here is a summary of what I am covering in this series on C#7.

Throw Expressions

We have all written code like this1:

I have omitted the exception arguments for brevity, but you should hopefully recognise the sort of sanity checking to which I am referring within the highlighted lines.

With throw expressions, we can now combine assignment, the null-coalescing operator2, and throw to create succinct validation code. This means that the example above can be simplified to not even need the constructor.

The highlighted lines are equivalent to the code we had earlier, but now we are able to use throw as part of the expression. The introduction of throw expressions means that we can now throw exceptions in conditional and null-coalescing expressions, as well as some lambda methods where it was previously not possible to do so. Not only that, but when combined with expression-bodied members, we can write some very expressive yet terse code.

Expression-bodied Members

With C#6 we got expression-bodied members, which allowed us to express simple methods using lambda-like syntax. However, this new syntax was limited to methods and read-only properties. Via the first ever community contribution to C#3, C#7 expands this syntax to cover constructors, finalizers, and property accessors.

If we take the property example we had before, containing our throw expression as part of  property set accessor, we can now write it as:

I won't bother with examples for constructors or finalizers; the main documentation is pretty clear on those and I am not convinced the syntax will be used very often in those cases. Constructors are rarely so simple that the expression-bodied syntax makes sense, and finalizers are so rarely needed4 that most of us will not get an opportunity to write one at all, expression-bodied or otherwise.

In Conclusion

These simple additions to the C# syntax enable us to write terse code without losing clarity, which is always a good thing. Not only that, but we have reached a landmark event; community contributions to C#. This contribution may be a little tame when compared with some of the other features coming in C#7, but it bodes well for the future of the language in its new, open source home.

Next time, we will take a look at the highly anticipated pattern matching. Until then, feel free to leave a comment, or read more about C#7 on my blog and on the official documentation.


  1. Let's ignore the nastiness of throwing exceptions during construction 

  2. You remember Elvis, right?? 

  3. Source: https://docs.microsoft.com/en-us/dotnet/articles/csharp/csharp-7#more-expression-bodied-members 

  4. If you find yourself writing a finalizer, I recommend you make sure you really need it; there is probably a better way 

C#6: Exception Filters

The for the last six1 releases the C# compiler has been keeping part of the .NET Framework secret from us2; exception filters. It turns out that the .NET Framework has supported exception filters since the very beginning, there was just no way to express them using C# until now.

C#6 adds the when keyword for use in try/catch blocks to specify exception filters. An exception filter is a predicate method that takes the thrown exception and returns true when the exception should be caught or false when it should not. If the filter says the exception should not be caught, the underlying system can continue to throw it.

This allows us to reduce the complexity in our code as we can put multiple catch statements with different filtering rules in the same try/catch block. This gives a switch style approach to exception handling that is supported at the lowest level, reducing the need to rethrow exceptions (or to remember the difference between throw; and throw exceptionVar;)3.

Here is a try/catch block showing an example of exception filtering:

Before I continue, I must state that this is a completely contrived example for demonstrable purposes; your filters would probably act on more than just the value of a string, the two filters shown would use the same code, and the handling would involve different things in each catch4.

Now, some things to note. First, the parentheses around the when condition are mandatory; you don't need to remember this as the compiler and syntax highlighting will remind you. Second, the content of the when condition must evaluate to bool; you cannot specify a lambda expression here. I am certain most of you already assumed that, but for some reason, I felt like that should be possible. However, when is akin to if or while, so it makes sense that a lambda expression would not work.

The example above provides three different catch blocks for the exact same exception type, ArgumentException. Each filter is evaluated in the order specified, so, if CallSomething() threw an ArgumentException with ParamName set to param2, the when condition on the first catch would reject it, but the second filter would catch it and handle accordingly. A ParamName value filtered out of the first two catch blocks would fall into the last.

In conclusion

Exception filtering is a useful and simple concept that should help to make exception handling easier to write. While some kind of filtering could be achieved before using conditions and throw inside of catch blocks, this language support now means that exception handlers (the content of catch blocks) have a single responsibility and the catch statements themselves are entirely responsible for declaring what must be caught. It also means that the exception handling within the .NET framework can be entirely responsible for routing exceptions in C#-implemented applications.

Exception filters have been supported by VB.NET and .NET-supporting variants of C++ since the versions released alongside .NET Framework 1.1; now, as of C#6, they are supported by C# too.


  1. 1.0, 1.2, 2.0, 3.0, 4.0, 5.0 

  2. Actually, it's been keeping several, but we can't have everything 

  3. The first rethrows the original exception with the stack unchanged, the second throws a new exception and resets the stack 

  4. otherwise, why filter? 

C#6: Support for .NET Framework 2.0 to 4.5

A colleague of mine, Eric Charnesky, asked me if C#6 language features would work in .NET Framework versions other than 4.6. I was pretty confident that the features were almost all1 just syntactical seasoning, I thought I would find out.

The TL;DR is yes, C#6 features will work when compiled against .NET 2.0 and above, with a few caveats.

  1. Async/await requires additional classes to be defined since the Task Parallel Library, IAwaitable and other types were not part of .NET 2.0.
  2. The magic parts of string interpolation need some types to be defined (thanks to Thomas Levesque for catching this oversight).
  3. Extension methods need the declaration of System.Runtime.CompilerServices.ExtensionAttribute so that the compiler can mark static methods as extension methods.

Rather than just try .NET 4.5, I decided to go all the way back to .NET 2.0 and see if I could write and execute a console application that used all the following C#6 features:

The code I used is not really important, though I have included it at the end of this post if you want to see what I did. The only mild stumbling block was the lack of obvious extension method support in .NET 2.0. However, extension methods are a language-only feature; all that is needed to make it work is an attribute that the compiler can use to mark methods as extension methods. Since .NET 2.0 doesn't have this attribute, I added it myself.

Exclusions

You might have noticed that I did not verify a couple of things. First, I left out the use of await in try/catch blocks. This is because .NET 2.0 does not include the BCL classes that the compiler expects when generating the state machines that drive async code. You might be able to find a third-party implementation that would add support, but my brief3 search was fruitless. That said, this feature will definitely work in .NET 4.5 as it is an update to how the compiler builds the code.

Second, I did not intentionally test the improved overload resolution. The improvements mostly seem to relate to resolution involving overloads that take method groups and nullable types. Unfortunately, in .NET 2.0 there was were no Func delegate types nor nullable value types (UPDATE: Nullable types totally existed in .NET 2.0 and C#2; thanks to Thomas Levesque for pointing out my strange oversight here – I blame the water), making it difficult to craft an example that would demonstrate this improvement. However, overload resolution affects how the compiler selects which method to use for a particular call site. Once the compiler has made the selection, it is fixed within the compiled output and as such, the version of the .NET framework has no bearing on whether the resolution is correct4.

Did it work?

With the test code written, I compiled and ran it. A console window flickered and Visual Studio returned. The code had run but I had forgotten to put anything in there that would give me chance to read the output. So, I dropped a breakpoint in at the end, and then ran it under the debugger. As I had suspected it might, everything worked.

Testing under .NET 2.0 runtime on Windows XP
Testing under .NET 2.0 runtime on Windows XP

Then I realised I was still executing it on a machine that had .NET 4.6 and therefore the .NET 4 runtime; would it still work under the .NET 2 runtime? So, I cracked open5 a Windows XP virtual machine from modern.ie and ran it again. It didn't work, because Windows XP did not come with .NET 2.0 installed (it wasn't even included in any of the service packs), so I installed it and tried once more. As I had suspected it might, everything worked.

In conclusion

If you find yourself still working with old versions of the .NET framework or the .NET runtime, you can still use and benefit from most features of C#6. I hope my small effort here is helpful. If you have anything to add, please comment.

Here Lies The Example Code6

 


  1. Async/await requires the TPL classes in the BCL, extension methods need the ExtensionAttribute, and exception filters require some runtime support 

  2. The Elvis's 

  3. very brief 

  4. I realise many of the C#6 features could be left untested for similar reasons since almost all are compiler changes that do not need framework support, but testing it rather than assuming it is kind of the point 

  5. Waited an hour for the IE XP virtual machine to download and then get it running 

  6. Demonstrable purposes only; if you take this into production, on your head be it 

Debugging in LINQPad

If you have been reading my blog over the last few months you will no doubt be aware that I am a regular user of LINQPad. I do not have any commercial involvement with LINQPad nor its creators, I just really like it. Recently, I decided to try out the latest release, which adds integrated debugging to the already feature rich tool. This amazingly powerful new feature adds yet another reason why this application should be in every developer's arsenal, regardless of experience and ability (it is a great learning tool for students). Here is a brief overview of this new feature, which is available with the premium license (currently on sale for $85 at time of writing; it may not be the case as you are reading this).

When running the latest LINQPad, the debugging feature adds some new buttons to the familiar toolbar. All the debugging features are available for both statement and program-based queries in C#, VB, and F# (not expressions or SQL languages). The first new button is the Pause button, also known as Break. This works as you might expect, pausing the current code execution. The other two are to specify how exceptions should be handled, informing  the debugger to break on unhandled exceptions and when exceptions are thrown. Breakpoints can be added by clicking in the margin to the left of the code or pressing F9 when the caret is on the desired line.  When a breakpoint is active on a line, it is indicated as a large red circle. For those who regularly use Visual Studio, the breakpoint and general debugger experience will be familiar.

Pressing F5 will run the query (or selected lines) as usual, but now, any breakpoints set on executing lines will cause the code to break. At this point, LINQPad will reveal some familar and not-so-familiar tools for debugging the code. General status information is displayed at the bottom of the LINQPad window, showing things like whether the code is executing or paused, whether the debugger is attached or not, and the process ID.

The next code statement to execute is highlighted in the code with a yellow arrow in the margin (in this case, overlaid on the breakpoint circle), and the code highlighted in yellow. In the lower left portion of the screen, we can see local variables and executing threads. We can also set up our own watches as necessary. Any objects in the Locals and Watch tabs can be expanded using the + glyph to reveal their constituent values. As in Visual Studio, these tabs allow the expansion of just-in-time LINQ queries so you can delve into the deep dark secrets of your code. However, you can also take advantage of LINQPad's fantastic dump feature and dump any value out to the Results tab on the right. If you want to control how far down the object graph a dump will go, you can modify the Dump Depth using the + and - controls in the column header.

The `Dump` output for the `range` variable
The Dump output for the range variable
Specifying the depth of the dump
Specifying the depth of the dump

For more information on LINQPad and its many features, check out the LINQPad website (http://linqpad.net). In my opinion, whether you use the free version or one of the paid upgrades, you will have one of the best coding utilities available for .NET.

Crash handling in Silverlight (Part Two)

This post is the second part of a two part series.

Adding a little polish

In part one of this series we learned about the basic out-of-the-box crash handling that a new Silverlight project provides for both in- and out-of-browser applications, we learned how we can catch unhandled exceptions inside our application or let them escape into the browser to be handled by JavaScript (or a bit of both) and we learned that we are at the mercy of the HTML bridge.

What we had was far from fancy; the user would end up with a potentially broken Silverlight application or a blank screen and only some cryptic text in the JavaScript console to explain. This is not how we make friends, but now that we have a foundation, we can look at how to enhance the experience for our quality departments, ourselves and the poor souls that must suffer for our mistakes, our users. However, some simple modifications to our error handler can move the cryptic text out of the console into the page. We can even add some pizzazz and remove most of the cryptic text too. So let's take what we were left with at the end of part one and add a little polish.

In the following example, I've constructed a simple page that gives the user some information and provides a mailto link for sending the details to our QA department. When a crash occurs, the Silverlight application is hidden and the error page is displayed, customized to the specific error code1 and information.

Now, I understand, this is not the most elegant JavaScript in the world, but it works. Here is what your user sees…

Example of what a user will see when the application crashes
Example of what a user will see when the application crashes

…and if the user clicks our mailto link, they'll get something like this…

Example of the auto-generated e-mail incident report
Example of the auto-generated e-mail incident report

The example could be expanded to add additional information such as the URL of the application, the version of Silverlight and the user agent string by just modifying the JavaScript to include that information2. You could even show the same information on the HTML page that you include in the e-mail (in fact, you can go even further than that, just use your imagination…or read on for some suggestions). And yes, a little CSS would help, but I never promised it would be pretty—pretty can come later; I'm aiming for functional and as functional goes for showing that something is non-functional, this is good enough.

A bridge too far

Of course, as we have access to all the wonders of HTML and JavaScript, we could do so much more. For example, we could play a video to entertain the user while we call a web service that sends our error report automatically to our servers and tweets an apology (it's the personal touches that count). However, it doesn't matter how fancy and special we make the crash experience, it is all for nought once the user installs and uses our application out-of-browser or the HTML bridge is disabled. So, what do we do?

Out of the browser and into the app

The simplest way I have found to handle crash reporting in an out-of-browser application (or an application that lacks the HTML bridge) is to throw up a ChildWindow containing the details of the crash and provide no discernible means to dismiss it, thus disabling your application from further use without closing the application. This relies on the Silverlight runtime remaining intact even though your application suffered a problem; however, from my experience, crashes that take out the runtime are rare, especially in applications that have been tested and have well-formed, correct XAML.

Of course, if the runtime is still working, why stop at a ChildWindow? If you have access to the Silverlight runtime, you could do more like call a web service call or use some trusted API3 or COM4 interface. Whatever you try, exercise caution as you don't want your crash handling to crash as well. Keep it simple and it will serve you well.

Conclusions

Whichever route you choose, you should work hard to cater for all the scenarios that might be encountered, that way you will provide the support your user deserves. When deciding on your crash reporting strategy, always consider:

  • What level of network connectivity might be available?
  • Will the application be in- or out-of-browser? Do you support both?
  • Will the application be trusted and therefore have access to COM or Windows APIs?5
  • What Silverlight runtime(s) will you want to support?

  1. If you were paying attention there, you may have noticed that I mentioned the error code. There are many error codes that can be reported by Silverlight. You can use the error code to tailor your report or even consider not reporting a crash at all, but that depends on just how badly your application will react to the error. 

  2. Getting the User Agent string or the site URL are relatively simple, especially when compared with retrieving the Silverlight runtime version from within JavaScript. Thankfully, this was solved already, just visit this blog for details. 

  3. Silveright 5 

  4. Silverlight 4 and up 

  5. Starting in Silverlight 5, both in- and out-of-browser trusted applications are supported. Earlier versions only support trusted applications when out-of-browser.