Using Multi-catch

[Schmichael Chen]

Hi,

All my question below is based on the paperback copy of the book: https://www.amazon.com/OCP-Certified-Professional-Programmer-1Z0-809/dp/1119067901?ie=UTF8&*Version*=1&*entries*=0

On Page 295, you have a snippet of code with line numbers. After the code snippet, you explained what happened inside the code snippet. Line # 22 does not throw an Exception and isn't it illegal/prohibited to catch it on Line 18 using catch(Exception e)?

The 2nd bullet point on Page 289 highlights what I've been talking about above. Basically the bullet point says that one can't catch a checked exception type that's not thrown from a try clause in order to avoid an unreachable code.

Thanks.

Schmichael

[Narayana Bojja]

Hi Schmichael Chen,

public class Demo {

	public static void main(String[] args) {

		try {
			mightThrow();
		} catch (Exception e) {

			e.printStackTrace();
		}
	}

	private static void mightThrow() throws DateTimeParseException, IOException {
	}

}

The above code compiles fine . mightThrow method doesn't generate any checked exception. But it is throwing a checked  exception by just declaring exception in its declaration. So when you are calling mightThrow , you must declare or handle that checked  exception even though it doesn't generate exception.

public class Demo {

	public static void main(String[] args) {

		try {
			mightThrow();
		} catch (Exception e) {

			e.printStackTrace();
		}
	}

	private static void mightThrow() throws DateTimeParseException {
	}

}

The above code doesn't compiles  . Because mightThrow method doesn't generate or or declared any checked  exception . So it is illegal to handle the checked exception.

public class Demo {

	public static void main(String[] args) throws Exception {

		mightThrow();

	}

	private static void mightThrow() throws DateTimeParseException {
	}

}

The above code compiles fine . Even though mightThrow method doesn't generate or or declared any checked  exception . You can declare the  checked exception.

Hope this helps !

[Ankit Garg]

Narayana Bojja wrote:

public class Demo {
	public static void main(String[] args) {
		try {
			mightThrow();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
	private static void mightThrow() throws DateTimeParseException {
	}

}

The above code doesn't compiles. Because mightThrow method doesn't generate or or declared any checked  exception . So it is illegal to handle the checked exception.

You sure about that? Exception has unchecked sub-classes (RuntimeException) so it is generally fine to catch it. If you try to catch a checked exception which doesn't have unchecked sub-classes then you get an error, so the following won't compile:

public class Demo {
	public static void main(String[] args) {
		try {
			mightThrow();
		} catch (IOException e) { // won't compile
			e.printStackTrace();
		}
	}
	private static void mightThrow() throws DateTimeParseException {
	}

}

[Paul Anilprem]

catch(Exception e) is always valid because as Ankur pointed out, RuntimeException is a subclass of Exception and any piece of code can throw a RuntimeException without declaring it to the compiler. Thus, the compiler has no option but to accept catch(Exception e).

While understanding such seemingly confusing rules, always remember that the compiler does not execute the code and that there are no objects in existence at compile time. Only references and types. The compiler merely looks at the information given in the program and makes inferences based on that information. Humans, while evaluating a piece of code, tend to execute the code mentally as they read the code. This makes us question the compiler,  "why can't the compiler see this is not true? This is obviously unreachable, why is the compiler allowing it? and so on"

[Schmichael Chen]

Narayana Bojja wrote:Hi Schmichael Chen,

public class Demo {

	public static void main(String[] args) {

		try {
			mightThrow();
		} catch (Exception e) {

			e.printStackTrace();
		}
	}

	private static void mightThrow() throws DateTimeParseException, IOException {
	}

}

The above code compiles fine . mightThrow method doesn't generate any checked exception. But it is throwing a checked  exception by just declaring exception in its declaration. So when you are calling mightThrow , you must declare or handle that checked  exception even though it doesn't generate exception.

public class Demo {

	public static void main(String[] args) {

		try {
			mightThrow();
		} catch (Exception e) {

			e.printStackTrace();
		}
	}

	private static void mightThrow() throws DateTimeParseException {
	}

}

The above code doesn't compiles  . Because mightThrow method doesn't generate or or declared any checked  exception . So it is illegal to handle the checked exception.

public class Demo {

	public static void main(String[] args) throws Exception {

		mightThrow();

	}

	private static void mightThrow() throws DateTimeParseException {
	}

}

The above code compiles fine . Even though mightThrow method doesn't generate or or declared any checked  exception . You can declare the  checked exception.

Hope this helps !

Thank you.

Schmichael

[Schmichael Chen]

Ankit Garg wrote:

Narayana Bojja wrote:

public class Demo {
	public static void main(String[] args) {
		try {
			mightThrow();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
	private static void mightThrow() throws DateTimeParseException {
	}

}

The above code doesn't compiles. Because mightThrow method doesn't generate or or declared any checked  exception . So it is illegal to handle the checked exception.

You sure about that? Exception has unchecked sub-classes (RuntimeException) so it is generally fine to catch it. If you try to catch a checked exception which doesn't have unchecked sub-classes then you get an error, so the following won't compile:

public class Demo {
	public static void main(String[] args) {
		try {
			mightThrow();
		} catch (IOException e) { // won't compile
			e.printStackTrace();
		}
	}
	private static void mightThrow() throws DateTimeParseException {
	}

}

Thank you.

Schmichael

[Schmichael Chen]

Paul Anilprem wrote:catch(Exception e) is always valid because as Ankur pointed out, RuntimeException is a subclass of Exception and any piece of code can throw a RuntimeException without declaring it to the compiler. Thus, the compiler has no option but to accept catch(Exception e).

While understanding such seemingly confusing rules, always remember that the compiler does not execute the code and that there are no objects in existence at compile time. Only references and types. The compiler merely looks at the information given in the program and makes inferences based on that information. Humans, while evaluating a piece of code, tend to execute the code mentally as they read the code. This makes us question the compiler,  "why can't the compiler see this is not true? This is obviously unreachable, why is the compiler allowing it? and so on"

Hi Paul,

How are you? Is that you? I asked a lot of questions on EnthuWare site and you generously answered a lot of my questions I had on mock exam questions. Thank you very much for this answer. Appreciate it.

Schmichael

[Schmichael Chen]

Paul Anilprem wrote:catch(Exception e) is always valid because as Ankur pointed out, RuntimeException is a subclass of Exception and any piece of code can throw a RuntimeException without declaring it to the compiler. Thus, the compiler has no option but to accept catch(Exception e).

While understanding such seemingly confusing rules, always remember that the compiler does not execute the code and that there are no objects in existence at compile time. Only references and types. The compiler merely looks at the information given in the program and makes inferences based on that information. Humans, while evaluating a piece of code, tend to execute the code mentally as they read the code. This makes us question the compiler,  "why can't the compiler see this is not true? This is obviously unreachable, why is the compiler allowing it? and so on"

Paul,

You said "There are no objects in existence at compile time."

I agree that the object begins to exist only after a constructor is invoked. Since the compiler has already seen the constructor, why can't the compiler invoke that constructor during the compile time, i.e. early binding? Thanks.

Schmichael

[Paul Clapham]

The compiler doesn't execute ANY code.

As for "Why can't it?", the response is "Why should it?" The compiler's purpose is to evaluate whether a class's code is correct according to the rules of Java. And the rules of Java are written in such a way that it's not necessary to execute any code to make that evaluation.

It's hard enough to write a compiler as it is, with a language specification of around 100 pages, without trying to make compilers execute code.

[Schmichael Chen]

Paul Clapham wrote:The compiler doesn't execute ANY code.

As for "Why can't it?", the response is "Why should it?" The compiler's purpose is to evaluate whether a class's code is correct according to the rules of Java. And the rules of Java are written in such a way that it's not necessary to execute any code to make that evaluation.

It's hard enough to write a compiler as it is, with a language specification of around 100 pages, without trying to make compilers execute code.

Thanks, Paul.

Schmichael