课程: Java Exception Handling

Exception: FileNotFoundException - Java教程

课程: Java Exception Handling

Exception: FileNotFoundException

- [Instructor] In this example, we will learn how to catch an exception. More specifically, the FileNet found exception, which is a type of checked exception and a type of IO exception. To do this, I added another method to the Fibonacci app called Get Sequence on line 38, this retrieve Fibonacci sequence method, on line 39 takes in a string file name. It uses that string file name on line 40 and passes it to the private helper method, gets sequenced defined on line 43. This method on line 44 uses the buffered reader to open the file with the specified file name. Online 45 read each line in the file and return it as one string. This file contains the Fibonacci sequence stored in the requested file. Notice on line 43, we indicate that this gets sequenced method will throw a FileNet found exception. This is very similar to what we have on line 39 for the parent exception, IO exception. Let's start up our application and try this get sequence endpoint. My application has started because I see the started Fibonacci application message at the bottom of my console. To make the requests. I am using the postman GUI to send a get request to the fibonacci/get sequence file name = Fibonacci.txt URL. The response for this existing TXT is returned, which includes zero, one, one, two. What happens though if I request a file name that does not exist? Let's give that a shot with a file called fib.txt, the response is not a user-friendly JSON object, and it's returning an HTTP status of 500 internal server error. Spring rests sees this IO exception or the file that found exception and uses the 500 as the generic response, any time it has an internal issue. And we do not specify specifically what status should be used. We would like to return more useful and helpful information to the user, so they know how to resolve it. This is where we could use a try-catch. Back in our retrieved fibonacci sequence method is where we could try a try-catch statement. We could try to retrieve a sequence from a file name and catch a specific exception and notify the user. On line 40, I will start my try-catch statement. I specifically want to try the get sequenced response. Because this is a try-catch. I actually want the variable that I'm storing my sequence in to start outside of my try-catch statement. This will allow me to pass the sequence variable into the response entity defined on line 44. On line 43, I will start my catch block and I wants to specifically catch the file that found exception and give it the variable name of E. with this catch statement, the file that found exception is the only exception that I am catching for now. This will be triggered anytime to get sequenced method throws the specified exception. When it does, we want to return a more specific response entity with the status of HTCP not found. And I want the body of my message to be some helpful message to the users, like file not available, please check requests and try again. We could also use the past and exception from our catch statement and retrieve any information from that exception. In this case, the get message method is what I'll use. Now restart my application To try a request from earlier. My application has started and when I try this same fib.txt request, I get back a string, body, this says FileNet available, please check requests and try again. In these specific, exception message of fib.txt, no such file or directory is also included. Note for security reasons. You may not want to share the exceptions message in the response to the user. Exceptions often have more details on the underlying structure of the code and potentially sharing this with the hacker, indicates a weakness in your code that they could leverage. Keep this in mind, when you're actually handling exceptions and production. Another thing of note is that the status in the top right-hand corner of our response here is a 404 not found. Previously it was a 500 internal server error. This makes the response more useful for future developers, as they may need to know how to troubleshoot this error on their end, if we kept it as the 500 exception, however, we would likely have to fill a lot of unnecessary support requests. Now that we know this try-catch works, let's discuss chaining try-catch statements. As you may recall, I have mentioned before that a file that found exception is a subclass of the IO exception. This is helpful to know for when we want to catch different types of exceptions. To illustrate this, I will start another catch statement on line 44, but this time I want to catch the IO exception. You will notice that my IDE underlined line 45 with an error. This is because both catch clauses are not around necessary since any FileNet found exceptions that are thrown will already be caught by the first catch phase on line 44. I could however, change the order and because FileNet found is a more specific exception. We want that to be caught first and then let any other IO exception that could possibly occur be caught by the second statement on line 47. However, again my editor gives me a warning this time that a FileNet found exception has already been cut. This is because we are working with a checked exception and our IDE already knows that this method will only throw one type of IO exception and that's FileNet found exception, making this catch statement on 47, unnecessary. We now have an understanding of how to try a piece of code and catch an exception. We also know how to chain catch clauses and keep in mind the exceptions and their subclasses and the order in which we catch them.

内容