Custom Exceptions6:23 with Jeremy McLain
We can use inheritance to create our own types of exceptions.
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 up