Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed C# Objects!
You have completed C# Objects!
Preview
We can use inheritance to create our own types of exceptions.
This video doesn't have any notes.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
We just learned that we can
make our own exception types.
0:00
Let's create a couple of our own.
0:03
Exception classes
are typically very small.
0:05
Sometimes when you have some small
classes that are very closely related to
0:09
each other it makes sense to
put them in the same file.
0:13
Let's create a file called,
Exceptions.cs to hold our exception types.
0:16
These exceptions will be specific
to the TreehouseDefense game, so
0:22
we'll put them in
the TreehouseDefense namespace.
0:26
One of the problems we have with
using System.Exception class is,
0:32
we don't know what code through it.
0:37
It could be coming from a method inside
the .NET framework that we called.
0:40
Or we might have thrown in
ourselves from the code written in
0:44
the TreehouseDefense game.
0:46
We can differentiate exceptions
that originate directly from
0:48
within the TreehouseDefense code.
0:51
From those coming from other code,
0:53
by creating an exception type that
specific to TreehouseDefense.
0:55
Let's create an exception class
called TreehouseDefenseException.
0:59
By convention all exception types used
in C# end with the word exception.
1:05
This isn't required.
1:11
It's just a convention.
1:12
Creating a new type of exception also
gives us the opportunity to practice using
1:14
inheritance again.
1:18
In C# all exception types must
inherit from System.Exception.
1:20
You see System.Exception is the most
general exception that can be thrown.
1:25
All other exceptions represent
exceptions that are more specific.
1:30
Just like a mammal is a more
specific type of animal.
1:34
So the TreehouseDefenseException
should be a subclass of
1:37
System.Exception We can even
make more specific exceptions.
1:41
Let's make one for
1:49
the case of a MapLocation being
created outside the bounds of a map.
1:50
We can throw this exception from
the MapLocation constructor,
1:55
instead of throwing the less
descriptive base exception type.
1:58
Let's call it OutOfBoundsException.
2:01
This exception type is specific
to the TreehouseDefense game.
2:08
So we'll have it inherit from
the TreehouseDefenseException.
2:12
That's right, you can keep inheriting
from subclasses like this.
2:17
You can have as many levels
of inheritance as you like.
2:22
We now have three levels of inheritance.
2:25
The OutOfBoundsException is a subclass
of the TreehouseDefenseException,
2:28
which is a subclass of
the most basic exception type.
2:32
We could make even more exception types,
but these will work for
2:36
what we need for right now.
2:39
Now let's go back to
the MapLocation constructor and
2:41
use this more specific exception type.
2:43
Now instead of using the basic
System.Exception class here
2:46
we'll change this to OutOfBoundsException.
2:51
Even though we're using a more
specific exception type here
2:54
it's still nice to provide
a human readable message.
2:58
The only problem is we haven't
written a constructor for
3:01
the OutOfBoundsException
that accepts a string.
3:04
So back here in exceptions.cs we'll add
3:07
a constructor to the OutOfBoundsException
that takes the message as a parameter.
3:09
It will forward the message to
the base class constructor.
3:14
If we were to compile this right now,
3:24
we'd get a compiler error because the base
class is TreehouseDefenseException.
3:26
And it doesn't have a constructor
that takes a message.
3:31
Let's try to compile to see
what that error looks like.
3:34
I see we've got a couple
of compiled errors here.
3:53
One of them is complaining that
the TreehouseDefenseException
3:56
does not contain a constructor
that takes one arguments.
4:00
That's because we're trying to call
it with the message parameter.
4:04
The other one is because I
forgot to add public here.
4:09
Let's do that now.
4:15
And let's add a constructor to
the TreehouseDefenseException.
4:17
We already know that the System.Exception
class has a constructor that
4:34
takes a string.
4:39
So we'll pass the message to it.
4:40
Let's compile again just
to make sure this works.
4:46
Don't actually wanna run.
4:54
I just wanna compile.
4:56
Okay, no compile errors.
4:58
Now we can create exceptions
that have messages.
5:01
Unfortunately, now that we've added a
constructor that takes a string parameter.
5:03
The only way to instantiate these
exceptions is to pass it a message.
5:08
Sometimes it doesn't make sense
to have a message though.
5:12
We still want the ability to create
exceptions that don't have messages.
5:15
To get this ability back, we need to add
constructors that don't have parameters.
5:19
So, I'll add a constructor to
the OutOfBoundsException that doesn't take
5:24
any parameters.
5:28
And I'll make one for
TreehouseDefenseException.
5:35
You notice that I didn't have to say colon
base here at the end of the constructor.
5:46
It's implied because this is
called the Default Constructor.
5:52
And when the default constructor is used,
5:56
it automatically calls the default
constructor of its base class.
5:59
So now each of these classes
has two constructors.
6:03
This is very similar to the method
overloading we did in the point class
6:07
with the distance to method.
6:10
We now have exception types with
various degrees of specificity.
6:12
In the next video, we'll look at how to
handle these different types of exceptions
6:17
using Try/Catch.
6:21
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up