Chapter 10 Exceptions Notes Flashcards

Question

**StackOverflowError**

Answer 1

When Java calls methods, it puts parameters and local variables on the stack. After doing this a very large number of times, **the stack runs out of room and overflows**. This is called a **StackOverflowError**. **Most of the time, this error occurs when a method calls itself.** ``` public static void doNotCodeThis(int num) { doNotCodeThis(1); } ``` The output contains this line: ``` Exception in thread "main" java.lang.StackOverflowError ``` Since the method calls itself, it will never end. Eventually, Java runs out of room on the stack and throws the error. This is called infinite recursion. It is better than an infinite loop because at least Java will catch it and throw the error. With an infinite loop, Java just uses all your CPU until you can kill the program.

Answer 2

A ***`NoClassDefFoundError`*** occurs **when Java can’t find the class at runtime**. Generally, this means a library available when the code was compiled is not available when the code is executed.

Answer 3

``` try { // Protected code } catch (expection_type identifier) { // Exception handler } ``` 1. The ***`try`*** keyword 2. Curly braces are required. 3. The ***`catch`*** keyword 4. the type of ***`exception`*** being caught 5. the identifier of the exception object * **The code in the try block is run normally**. * **If any of the statements throws an exception that can be caught by the exception type listed in the catch block**, * **the try block stops running and execution goes to the catch statement.** * **If none of the statements in the try block throws an exception that can be caught, the catch clause is not run.** * You probably noticed the words **block and clause** used interchangeably. * The exam does this as well, so get used to it. Both are correct. * Block is correct because there are braces present. * Clause is correct because they are part of a try statement. * There aren’t a ton of syntax rules here. * **The curly braces are required for the try and catch blocks.**

Answer 4

* First, line 5 calls the fall() method. * Line 12 throws an exception. * This means Java jumps straight to the catch block, skipping line 6. The girl gets up on line 8. * Now the try statement is over, and execution proceeds normally with line 10.

Answer 5

The problem is that the braces {} are missing. It needs to look like this: ``` try { fall(); } catch (Exception e) { System.out.println("get up"); } ``` The try statements are like methods in that the curly braces are required even if there is only one statement inside the code blocks, while if statements and loops are special and allow you to omit the curly braces.

Answer 6

* This code doesn’t compile because the try block doesn’t have anything after it. * Remember, the point of a try statement is for something to happen if an exception is thrown. Without another clause, the try statement is lonely. * As you will see shortly, there is a special type of try statement that includes an implicit finally block, although the syntax for this is quite different from this example.

Answer 7

A rule exists for the **order of the catch blocks**. Java looks at them in the order they appear. If it is impossible for one of the catch blocks to be executed, a **compiler error** about **unreachable code** occurs. For example, this happens when a **superclass catch block appears before a subclass catch block**. Remember, we warned you to pay attention to any subclass exceptions. ``` class AnimalsOutForAWalk extends RuntimeException { } class ExhibitClosed extends RuntimeException { } class ExhibitClosedForLunch extends ExhibitClosed { } ``` ``` public void visitPorcupine() { try { seeAnimal(); } catch (AnimalsOutForAWalk e) { // first catch block System.out.print("try back later"); } catch (ExhibitClosed e) { // second catch block System.out.print("not today"); } } ``` ``` public void visitMonkeys() { try { seeAnimal(); } catch (ExhibitClosedForLunch e) { // subclass exception System.out.print("try back later"); } catch (ExhibitClosed e) { // superclass exception System.out.print("not today"); } } ``` ``` public void visitMonkeys() { try { seeAnimal(); } catch (ExhibitClosed e) { System.out.print("not today"); } catch (ExhibitClosedForLunch e) { // DOES NOT COMPILE System.out.print("try back later"); } } ``` This time, if the more specific ExhibitClosedForLunch exception is thrown, the catch block for ExhibitClosed runs—which means there is no way for the second catch block to ever run. Java correctly tells you there is an **unreachable catch block.**

Answer 8

Remember we said earlier you needed to know that NumberFormatException is a subclass of IllegalArgumentException? This example is the reason why. Since NumberFormatException is a subclass, it will always be caught by the first catch block, making the second catch block unreachable code that does not compile. Likewise, for the exam you need to know that FileNotFoundException is subclass of IOException and cannot be used in a similar manner.

Answer 9

* To review multiple catch blocks, remember that **at most *one* catch block will run**, and it will be the ***first* catch block that can handle it**. * Also, remember that **an exception defined by the catch statement is only in *scope* for that catch block.** * the example causes a **compiler error since it tries to use the exception class outside the block** for which it was defined.

Answer 10

``` public static void main(String args[]) { try { System.out.println(Integer.parseInt(args[1])); } catch (ArrayIndexOutOfBoundsException e) { System.out.println("Missing or invalid input"); } catch (NumberFormatException e) { System.out.println("Missing or invalid input"); } } ``` reduce the duplicate code A multi-catch block allows multiple exception types to be caught by the same catch block. ``` public static void main(String[] args) { try { System.out.println(Integer.parseInt(args[1])); } catch (ArrayIndexOutOfBoundsException | NumberFormatException e) { System.out.println("Missing or invalid input"); } } ``` **Remember that the exceptions can be listed in any order within the catch clause. However, the variable name must appear only once and at the end.** ``` catch(Exception1 e | Exception2 e | Exception3 e) // DOES NOT COMPILE catch(Exception1 e1 | Exception2 e2 | Exception3 e3) // DOES NOT COMPILE catch(Exception1 | Exception2 | Exception3 e) ```

Answer 11

Specifying it in the multi-catch is redundant, and the compiler gives a message such as this: ``` The exception FileNotFoundException is already caught by the alternative IOException ``` Since FileNotFoundException is a subclass of IOException, this code will not compile. A multi-catch block follows similar rules as chaining catch blocks together that you saw in the previous section. For example, both trigger compiler errors when they encounter unreachable code or duplicate exceptions being caught. The one difference between multi-catch blocks and chaining catch blocks is that order does not matter for a multi-catch block within a single catch expression. ``` try { throw new IOException(); } catch (IOException e) { } ```

Answer 12

This code is just swimming with errors. In fact, some errors hide others, so you might not see them all in the compiler. Once you start fixing some errors, you’ll see the others. Here’s what’s wrong: * Line 15 has an extra variable name. Remember that there can be only one exception variable per catch block. * Line 16 cannot catch FileNotFoundException because that exception was already caught on line 14. You can’t list the same exception type more than once in the same try statement, just like with “regular” catch blocks. * Lines 17 and 18 are reversed. The more general superclasses must be caught after their subclasses. While this doesn’t have anything to do with multi-catch, you’ll see “regular” catch block problems mixed in with multi-catch.

Answer 13

``` try { // Protected code } catch (expection_type identifier) { // Exception handler } finally { // finally block } ``` * The catch block is optional when finally is used * The finally keyword * The finally block always executes, whether or not an exception occurs. * Code does not compile if catch and finally block in wrong order * Code does not compile if try statement do not have a catch or finally block. * The catch block is not required if finally is present.

Answer 14

There is one additional rule you should know for finally blocks. If a try statement with a finally block is entered, then the finally block will always be executed, regardless of whether the code completes successfully. * If an exception is not thrown on line 14, then the line 15 will be executed, printing 1. * Before the method returns, though, the finally block is executed, printing 3. * If an exception is thrown, then lines 15–16 will be skipped, and lines 17–19 will be executed, printing 2, followed by 3 from the finally block. * While the first value printed may differ, the method always prints 3 last since it’s in the finally block. * What is the return value of the goHome() method? In this case, **it’s always -3**. Because the finally block is executed shortly before the method completes, **it interrupts the return statement from inside both the try and catch blocks.**

Answer 15

* If info is null, then the finally block would be executed, but it would stop on line 32 and throw a NullPointerException. * Lines 33–34 would not be executed. * In this example, you see that while a **finally block will always be executed, it may not finish.**

Answer 16

There is one exception to “the finally block always be executed” rule: Java defines a method that you call as System.exit(). It takes an integer parameter that represents the error code that gets returned. ``` try { System.exit(0); } finally { System.out.print("Never going to get here"); // Not printed } ``` System.exit() tells Java, “Stop. End the program right now. Do not pass go. Do not collect $200.” **When System.exit() is called in the try or catch block, the finally block does not run.**

Answer 17

files, databases, and various connection objects these external data sources are referred to as ***`resources`***. In many cases, you **open a connection to the resource** then **read/write the data** Finally, you **close the resource** to indicate you are done with it. resource leak if you don’t close a resource when a program fails to release its connections to a resource, resulting in the resource becoming inaccessible. ``` 4: public void readFile(String file) { 5: FileInputStream is = null; 6: try { 7: is = new FileInputStream("myfile.txt"); 8: // Read file data 9: } catch (IOException e) { 10: e.printStackTrace(); 11: } finally { 12: if(is != null) { 13: try { 14: is.close(); 15: } catch (IOException e2) { 16: e2.printStackTrace(); 17: } 18: } 19: } 20: } ```

Answer 18

``` 4: public void readFile(String file) { 5: try (FileInputStream is = new FileInputStream("myfile.txt")) { 6: // Read file data 7: } catch (IOException e) { 8: e.printStackTrace(); 9: } 10: } ``` by using a try-with-resources statement, we guarantee that as soon as a connection passes out of scope, Java will attempt to close it within the same method.

Answer 19

Behind the scenes, the compiler replaces a try-with-resources block with a try and finally block. We refer to this “hidden” finally block as an implicit finally block since it is created and used by the compiler automatically. You can still create a programmer-defined finally block when using a try-with-resources statement; just be aware that the implicit one will be called first.

Answer 20

* **one or more resources can be opened in the try clause.** * When there are multiple resources opened, they are closed in the reverse order from which they were created. * parentheses are used to list those resources, and semicolons are used to separate the declarations. ``` try (FileInputStream in = new FileInputStream("data.txt"); FileOutputStream out = new FileOutputStream("output");) { // Protected code } ``` * Any resources that should automatically be closed (in parentheses) * Required semicolon between resource declarations * Last semicolon is optional (usually omitted) * Resources are closed at this point (end of try statement).

Answer 21

try statement must have one or more catch blocks or a finally block. This is still true. The finally clause exists implicitly. You just don’t have to type it.

Answer 22

* try-with-resources statement is still allowed to have catch and/or finally blocks. * In fact, if the code within the try block throws a checked exception not declared by the method in which it is defined or handled by another try/catch block, then it will need to be handled by the catch block. * Also, the catch and finally blocks are run in addition to the implicit one that closes the resources. * For the exam, you need to know that the implicit finally block runs before any programmer-coded ones.

Answer 23

Illegal 1. No catch and finally statement 2. More than 1 finally statement Legal 1. 1 finally statement 2. 1 or more catch statement 3. 1 finaly and 1 or more catch statement

Answer 24

Illegal 1. More than 1 finally statement Legal 1. No catch and finally statement 2. 1 finally statement 2. 1 or more catch statement 3. 1 finaly and 1 or more catch statement

Answer 25

* You can’t just put any random class in a try-with-resources statement. * Java requires classes used in a **try-with-resources** implement the **AutoCloseable** interface, which includes a void **close()** method.

Answer 26

* try-with-resources does support declaring multiple variables, **each variable must be declared in a separate statement.** * Each resource must include the data type and be separated by a **semicolon (;)**. * You can declare a resource using **var** as the data type in a try-with-resources statement, since resources are **local variables**. ``` try (MyFileClass is = new MyFileClass(1), // DOES NOT COMPILE os = new MyFileClass(2)) { } ``` does not compile because it is missing the data type and it uses a comma (,) instead of a semicolon (;). ``` try (MyFileClass ab = new MyFileClass(1), // DOES NOT COMPILE MyFileClass cd = new MyFileClass(2)) { } ``` does not compile because it also uses a comma (,) instead of a semicolon (;) ``` try (var f = new BufferedInputStream(new FileInputStream("it.txt"))) { // Process file } ```

Answer 27

* The **resources** created in the try clause are in **scope only within the try block.** * This is another way to remember that the **implicit finally runs before any catch/finally blocks** that you code yourself. * The implicit close has run already, and the resource is no longer available. ``` 3: try (Scanner s = new Scanner(System.in)) { 4: s.nextLine(); 5: } catch(Exception e) { 6: s.nextInt(); // DOES NOT COMPILE 7: } finally { 8: s.nextInt(); // DOES NOT COMPILE 9: } ``` * The problem is that Scanner has gone out of scope at the end of the try clause. Lines 6 and 8 do not have access to it. * **This is actually a nice feature. You can’t accidentally use an object that has been closed.**

Answer 28

* Resources are closed after the try clause ends and before any catch/finally clauses. * Resources are closed in the reverse order from which they were created.

Answer 29

First, we define a custom class that you can use with a try-with-resources statement, as it implements AutoCloseable. ``` public class MyFileClass implements AutoCloseable { private final int num; public MyFileClass(int num) { this.num = num; } public void close() { System.out.println("Closing: " + num); } } ``` ``` public static void main(String... xyz) { try (MyFileClass a1 = new MyFileClass(1); MyFileClass a2 = new MyFileClass(2)) { throw new RuntimeException(); } catch (Exception e) { System.out.println("ex"); } finally { System.out.println("finally"); } } ``` The output is as follows: ``` Closing: 2 Closing: 1 ex finally ```

Answer 30

**Does a try-with-resources statement guarantee a resource will be closed?** the short answer is “no.” * **The try-with-resources statement guarantees only the close() method will be called.** * If the close() method encounters an exception of its own or the method is implemented poorly, a resource leak can still occur.

Answer 31

What happens when an exception is thrown inside of a catch or finally block? ``` 16: public static void main(String[] a) { 17: FileReader reader = null; 18: try { 19: reader = read(); 20: } catch (IOException e) { 21: try { 22: if (reader != null) reader.close(); 23: } catch (IOException inner) { 24: } 25: } 26: } 27: private static FileReader read() throws IOException { 28: // CODE GOES HERE 29: } ```

Answer 32

The correct answer is **`before_catch_finally_done`**. * First on line 35, **"before`_`"** is added. * Line 36 throws a NullPointerException. * Line 37 is skipped as Java goes straight to the catch block. * Line 38 does catch the exception, and **"catch`_`"** is added on line 39. * Then line 40 throws a RuntimeException. * The finally block runs after the catch regardless of whether an exception is thrown; it adds **"finally`_`"** to result. At this point, we have completed the inner try statement that ran on lines 34`–`44. * The outer catch block then sees an exception was thrown and catches it on line 45; it adds **"done"** to result.

Answer 33

``` class NoMoreCarrotsException extends Exception {} public class Bunny { public static void main(String[] args) { eatCarrot(); // DOES NOT COMPILE } private static void eatCarrot() throws NoMoreCarrotsException { } } ``` * The problem is that NoMoreCarrotsException is a checked exception. * Checked exceptions must be handled or declared. * The code would compile if you changed the main() method to either of these: declared: ``` public static void main(String[] args) throws NoMoreCarrotsException { // declare exception eatCarrot(); } ``` handled ``` public static void main(String[] args) { try { eatCarrot(); } catch (NoMoreCarrotsException e ) { // handle exception System.out.print("sad rabbit"); } } ```

Answer 34

* Java knows that eatCarrot() can’t throw a checked exception— * which means there’s **no way for the catch block in bad() to be reached.** * In comparison, good() is **free to declare** other exceptions.

Answer 35

When a class overrides a method from a superclass or implements a method from an interface, it’s **not allowed to add new checked exceptions** to the method signature. ``` class CanNotHopException extends Exception { } class Hopper { public void hop() { } } class Bunny extends Hopper { public void hop() throws CanNotHopException { } // DOES NOT COMPILE } ``` An overridden method in a subclass is **allowed to declare fewer exceptions** than the superclass or interface. This is legal because callers are already handling them. ``` class Hopper { public void hop() throws CanNotHopException { } } class Bunny extends Hopper { public void hop() { } } ``` An overridden method not declaring one of the exceptions thrown by the parent method is similar to the method declaring it throws an exception that it never actually throws. This is perfectly legal. a class is **allowed to declare a subclass of an exception type**. The idea is the same. The superclass or interface has already taken care of a broader type. Here’s an example: ``` class Hopper { public void hop() throws Exception { } } class Bunny extends Hopper { public void hop() throws CanNotHopException { } } ``` This rule **applies only to checked exceptions**. The following code is legal because it has an unchecked exception in the subclass’s version: ``` class Hopper { public void hop() { } } class Bunny extends Hopper { public void hop() throws IllegalStateException { } } ```

Answer 36

There are **three** ways to print an exception. ``` 5: public static void main(String[] args) { 6: try { 7: hop(); 8: } catch (Exception e) { 9: System.out.println(e); // 1 10: System.out.println(e.getMessage()); // 2 11: e.printStackTrace(); // 3 12: } 13: } 14: private static void hop() { 15: throw new RuntimeException("cannot hop"); 16: } ``` output: ``` java.lang.RuntimeException: cannot hop cannot hop java.lang.RuntimeException: cannot hop at Handling.hop(Handling.java:15) at Handling.main(Handling.java:7) ```

Answer 37

``` public static void main(String... p) { String textInFile = null; try { textInFile = readInFile(); } catch (IOException e) { // ignore exception } // imagine many lines of code here System.out.println(textInFile.replace(" ", "")); } private static String readInFile() throws IOException { throw new IOException(); } ``` The code results in a NullPointerException. Java doesn’t tell you anything about the original IOException because it was handled. Granted, it was handled poorly, but it was handled.

Chapter 10 Exceptions Notes Flashcards

Exceptions (64 cards)