 Let's talk about when to use exceptions and when not to use exceptions. Here's some code from an earlier video, where I ask for a dividend and divisor, and then calculate the quotient and remainder. This program uses arithmetic exception to make sure the program doesn't crash if the user tries to divide by zero. I feel a little bit guilty about having shown you this code, because it's really misusing arithmetic exception. If I want to avoid that division by zero, I can just as well do it with an if statement and not have to do the extra work for both me and the Java virtual machine of setting up an exception and a try catch block. Similarly, in code like this, where I'm using an index out of bounds exception to make sure that the user enters a number that's inside the array bounds, I really shouldn't be using an exception, when an if else statement will do the job just as well. Why did I have them in the other videos? Because I needed an example, and those were the most directly understandable ones that I could use. What about the input mismatch exception? I'm keeping that one in both programs, because testing for whether an input string is actually a number isn't something you can handle with a simple if condition. There's another situation where you want to use exceptions instead of if else, when you're creating a library for other people to use. Consider this code that's part of an array utilities library. We have a max method that finds the maximum value in a data array. What happens if the person who's using our code passes an empty array into our max method? That's an error and we have to handle it. What we don't want to do is to put in an if statement that prints out an error message, because we don't know who's going to be using our library. Maybe they want an error message, maybe they don't. We also have to return some value. What should we return for an empty array? Should we return zero as a result? No, again, we don't know what the user wants to do. Maybe they're using zero as a sentinel value and that would cause problems for them. In this case, we want the code to throw an exception. The user can then catch it and do whatever they want. Right now, the code throws an index out of bounds exception when given an empty array. We can improve on that by throwing an exception of our own. In the max method, we're going to put an if statement. If the length of the data array is greater than zero, we're good to go. Otherwise, we're going to throw a new illegal argument exception. When you create an exception, you can give the constructor a string with the error message that you want. In this case, we'll say the array length must be greater than zero. We'll also want to say that this method throws an illegal argument exception in case of error. You don't have to do this, but it's a good idea to make it explicit. Now when we recompile and rerun, we still get an exception, but it's customized to help our library's users fix their error. In summary, don't use try and catch when an if statement will do the job just as well. When writing methods for other people to use, don't guess what kind of error processing they'll need. Throw an exception and let the users handle the error as they see fit.