Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
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