Exceptions is an ancient programming concept that every developer has to deal with in the programs they write during development, testing and production scenarios. Visual Studio has long provided facilities to inspect the exceptions but with Visual Studio 2017, its Exception Helper dialog makes that process even easier.
In order to set the stage, let’s look at the following piece of code, specially the line shown in red rectangle below.
As you can see, there are various properties invoked for different objects on this line without ensuring that these objects are not null. This type of code can cause tricky situations to deal with specially in a production environment as I described in one of my articles for Visual Studio Magazine.
Let’s say, when debugging this application in Visual Studio 2015, an exception is thrown on the same line of code. In this case, Visual Studio 2015 will display the following dialog.
It's showing that a NullReferenceException has been caused on the same line but without much details about which object is responsible for the exception. Clicking on View Detail here brings up the following dialog.
This dialog is also not telling us either about the object causing the exception. Obviously, if you are debugging this code, you can inspect all related objects to determine the culprit but this is exactly where Visual Studio 2017 Exception Helper can save some of that time.
Same program when debugged under Visual Studio 2017 presents the following dialog.
As you can see in this case, Visual Studio 2017 is clearly showing that it's the product.Detail object returning a null causing the exception. Isn’t it great and a time saver?
There are many other tit-bits that you can do with this Exception Helper in Visual Studio 2017 that I will continue to explore in my upcoming blog posts.
Until next, happy debugging!!
Filed under: CodeProject, Visual Studio 2017
