SCJP study notes:Chapter 5 Flow Control and Exceptions

Originally written byVelmurugan Periasamy. Copyright belongs to him.

Chapter 5 Flow Control and Exceptions

· Unreachable statements produce a compile-time error.

while (false) { x = 3; } // won’t compile

for (;false;) { x =3; } // won’t compile

if (false) {x = 3; } // will compile, to provide the ability to conditionally compile the code.

· Local variables already declared in an enclosing block, therefore visible in a nested block cannot be re-declared inside the nested block.

· A local variable in a block may be re-declared in another local block, if the blocks are disjoint.

· Method parameters cannot be re-declared.

1. Loop constructs

· 3 constructs – for, while, do

· All loops are controlled by a boolean expression.

· In while and for, the test occurs at the top, so if the test fails at the first time, body of the loop might not be executed at all.

· In do, test occurs at the bottom, so the body is executed at least once.

· In for, we can declare multiple variables in the first part of the loop separated by commas, also we can have multiple statements in the third part separated by commas.

· In the first section of for statement, we can have a list of declaration statements or a list of expression statements, but not both. We cannot mix them.

· All expressions in the third section of for statement will always execute, even if the first expression makes the loop condition false. There is no short –circuit here.

2. Selection Statements

· if takes a boolean arguments. Parenthesis required. else part is optional. else if structure provides multiple selective branching.

· switch takes an argument of byte, short, char or int.(assignment compatible to int)

· case value should be a constant expression that can be evaluated at compile time.

· Compiler checks each case value against the range of the switch expression’s data type. The following code won’t compile.

byte b;

switch (b) {

case 200: // 200 not in range of byte

default:

}

· We need to place a break statement in each case block to prevent the execution to fall through other case blocks. But this is not a part of switch statement and not enforced by the compiler.

· We can have multiple case statements execute the same code. Just list them one by one.

· default case can be placed anywhere. It’ll be executed only if none of the case values match.

· switch can be nested. Nested case labels are independent, don’t clash with outer case labels.

· Empty switch construct is a valid construct. But any statement within the switch block should come under a case label or the default case label.

3. Branching statements

· break statement can be used with any kind of loop or a switch statement or just a labeled block.

· continue statement can be used with only a loop (any kind of loop).

· Loops can have labels. We can use break and continue statements to branch out of multiple levels of nested loops using labels.

· Names of the labels follow the same rules as the name of the variables.(Identifiers)

· Labels can have the same name, as long as they don’t enclose one another.

· There is no restriction against using the same identifier as a label and as the name of a package, class, interface, method, field, parameter, or local variable.

4. Exception Handling

· An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions.

· There are 3 main advantages for exceptions:

1. Separates error handling code from “regular” code

2. Propagating errors up the call stack (without tedious programming)

3. Grouping error types and error differentiation

· An exception causes a jump to the end of try block. If the exception occurred in a method called from a try block, the called method is abandoned.

· If there’s a catch block for the occurred exception or a parent class of the exception, the exception is now considered handled.

· At least one ‘catch’ block or one ‘finally’ block must accompany a ‘try’ statement. If all 3 blocks are present, the order is important. (try/catch/finally)

· finally and catch can come only with try, they cannot appear on their own.

· Regardless of whether or not an exception occurred or whether or not it was handled, if there is a finally block, it’ll be executed always. (Even if there is a return statement in try block).

· System.exit() and error conditions are the only exceptions where finally block is not executed.

· If there was no exception or the exception was handled, execution continues at the statement after the try/catch/finally blocks.

· If the exception is not handled, the process repeats looking for next enclosing try block up the call hierarchy. If this search reaches the top level of the hierarchy (the point at which the thread was created), then the thread is killed and message stack trace is dumped to System.err.

· Use throw new xxxException() to throw an exception. If the thrown object is null, a NullPointerException will be thrown at the handler.

· If an exception handler re-throws an exception (throw in a catch block), same rules apply. Either you need to have a try/catch within the catch or specify the entire method as throwing the exception that’s being re-thrown in the catch block. Catch blocks at the same level will not handle the exceptions thrown in a catch block – it needs its own handlers.

· The method fillInStackTrace() in Throwable class throws a Throwable object. It will be useful when re-throwing an exception or error.

· The Java language requires that methods either catch or specify all checked exceptions that can be thrown within the scope of that method.

· All objects of type java.lang.Exception are checked exceptions. (Except the classes under java.lang.RuntimeException) If any method that contains lines of code that might throw checked exceptions, compiler checks whether you’ve handled the exceptions or you’ve declared the methods as throwing the exceptions. Hence the name checked exceptions.

· If there’s no code in try block that may throw exceptions specified in the catch blocks, compiler will produce an error. (This is not the case for super-class Exception)

· Java.lang.RuntimeException and java.lang.Error need not be handled or declared.

· An overriding method may not throw a checked exception unless the overridden method also throws that exception or a super-class of that exception. In other words, an overriding method may not throw checked exceptions that are not thrown by the overridden method. If we allow the overriding methods in sub-classes to throw more general exceptions than the overridden method in the parent class, then the compiler has no way of checking the exceptions the sub-class might throw. (If we declared a parent class variable and at runtime it refers to sub-class object) This violates the concept of checked exceptions and the sub-classes would be able to by-pass the enforced checks done by the compiler for checked exceptions. This should not be allowed.

Here is the exception hierarchy.

Object

|

|

Throwable | |

| |

| |

| Error

|

|

Exception-->ClassNotFoundException, ClassNotSupportedException, IllegalAccessException, InstantiationException, IterruptedException, NoSuchMethodException, RuntimeException, AWTException, IOException

RuntimeException-->EmptyStackException, NoSuchElementException, ArithmeticException, ArrayStoreException, ClassCastException, IllegalArgumentException, IllegalMonitorStateException,

IndexOutOfBoundsException, NegativeArraySizeException, NullPointerException, SecurityException.

IllegalArgumentException-->IllegalThreadStateException, NumberFormatException

IndexOutOfBoundsException-->ArrayIndexOutOfBoundsException, StringIndexOutOfBoundsException

IOException-->EOFException, FileNotFoundException, InterruptedIOException, UTFDataFormatException, MalformedURLException, ProtocolException, SockException, UnknownHostException, UnknownServiceException.