If an exception is thrown while debugging and

nothing handles it., the debugger breaks and alerts us to the condition.

Let's take a deeper look at how Visual Studio helps us to debug exceptions.

Let's say for example, that we forgot to initialize the song variable up here.

Now let's start debugging.

I'll enter option 2 here.

When the program gets here, it throws an exception

because songs is null, and we can't call the for each method on a null variable.

When the debugger pauses as a result of an exception,

we get this pop up that contains a bunch of additional information.

Here we can see the exception name, and here,

right beside additional information, we can see the exception's message.

It says, object reference not set to an instance of an object.

Visual Studio provides some debugging tips for

many of the most common exception types.

We can see even more information about the exception

by clicking on View Details down here.

Here we see the contents of the exception object.

This often has a lot of really useful information.

Here we can see if there was an inner exception or

an exception that caused this exception.

We can also see the stack trace up to the point where the exception was thrown.

This is often different than the stack trace that is shown

in the call stack window.

Because the exception could have been thrown from external code, and

where the debugger has paused is just the first place where it is propagated back

to our code.

Visual Studio will pause the debugger for all unhandled exceptions.

But what about exceptions we have handlers for?

Sometimes we still want to break at the point where these

exceptions are thrown too.

Let's wrap this line by adding a try catch around it.

We'll go ahead and handle all exception types by catching System.exception.

And I'll just do nothing here.

I should mention that catching all exception types and

doing nothing is a really bad programming practice.

But again, this is just for demonstration purposes.

Now let's start the debugger and see what happens.

Again, I'll hit option two here.

Because we are now handling the exception,

the debugger no longer breaks when the exception is thrown.

We can tell it to continue breaking by going into the exception settings window.

If the exception settings window isn't already open,

you can open it from the debug menu under Windows.

You can also often find it down here.

Here we see many categories of exceptions.

Because this is a C Sharp program,

we're mostly interested in the Common Language Runtime exceptions.

These other exception types don't apply to us right now.

We can scroll down here and find the null reference exception,

or we can just type system.null, and it will find it for us quickly.

By clicking on this checkbox, we're telling Visual Studio to break on this

exception, even if it is handled at some point in the code.

Now if we restart the debugger and enter option 2 again,

we'll see that it breaks on line 42 of program that CS.

Notice that this list only contains exceptions provided by the .Net framework.

We can add our own custom exceptions by right clicking

on Common Language Runtime Exceptions, and clicking Add Exception.

Now we can add our own exception type with its full namespace name.

We don't have any custom exceptions in our program so far, but

this is a good thing to be aware of in the future.

There are a keyboard shortcuts for just about everything we've talked about here.

Often times using a keyboard can make coding debugging and

navigating around the code much more efficient.

Check out the link in the teacher's notes for a list of the fall short cuts.

I hope you feel much more comfortable debugging in Visual Studio.

I think you'll find having a good debugger at your fingertips can

make it a lot easier to track down pesky bugs the crop up from time to time.

Until next time, happy coding.