Welcome to another part of the series C# From Scratch, a course dedicated to teaching you everything you need to know to be productive with the C# programming language.
In the previous part of the series, we learned how to make our application interactive — the output of the application varies depending on the input provided by the user. If you missed it, that part of the series is available here.
While updating the application, we introduced a small bug — the application now crashes if the user fails to provide the correct input. In this part of the series, we’ll learn about exceptions and how to interpret exception messages to figure out why our application is crashing.
The .NET Runtime is responsible for managing your application while it’s running on a machine.
One of the main responsibilities of the .NET Runtime is to make sure that your application doesn’t do anything that is obviously wrong. If .NET lets your application do things that were obviously wrong, the application could corrupt data or damage the machine that it is running on.
When the .NET Runtime believes that your application is doing something wrong, it forces your application to throw an exception. An exception is an error condition, it indicates that something exceptional has happened in your application.
When an exception is thrown, one of two things will happen:
- The program will handle the exception and continue running
- The exception will go unhandled and the program will crash
.NET won’t allow your program to continue running with an unhandled exception. That’s because if an exception is unhandled, there is a high probability that the developer didn’t think that this exception could occur and the program may be in a faulty state. As I’m sure you have experienced, applications in faulty states can do awful things like corrupting data or causing the whole machine to freeze up.
We’ll talk about exceptions and exception handling in more detail later in the series.
Interpreting Unhandled Exceptions
The first step to fixing an unhandled exception in your application is to find where in your application it is occurring. Thankfully, .NET provides some useful information about exceptions when they occur.
In the error message, .NET tells you which line of code the exception occurred on. In this case, we can see that an unhandled exception occurred on line 9 of Program.cs.
The exception message provides additional context about the exception that occurred. This message includes information about the variable involved (in this case, args) and the type of exception that occurred (in this case, IndexOutOfRangeException).
Using this contextual information, we can already figure out what is going wrong with our program. It looks like we are trying to access an element in the args array that doesn’t exist.
By interpreting the exception message provided by .NET, we can begin to understand why our application is crashing and what code is causing it to crash.
Once we know where in the program to look, we can use a tool called a debugger to execute our program in a controlled environment. In this controlled environment, we can execute our application line by line and inspect the environment as the application executes.
In this way, we can find the root cause of exceptions that occur while our application is executing.
In the next part of the series, we’ll learn how to use the Visual Studio Code Debugger to find the root cause of exceptions in our application.
Missed a part of the series? You can find an overview of the series and links to all previous parts on the index page.