AI InterviewSearch…Search problems, topics, or pages…Ctrl KGet started
Skip to content

12 Exceptions / Checkpoint

Checkpoint — Exceptions

24 min · +25 XP · 3 exercises · 14 questions

Exercises0/3
Quiz · 70% to clear14 q

This checkpoint covers the exception hierarchy, checked versus unchecked, try/catch/finally semantics, try-with-resources, custom exceptions with chaining, and the handling practices.

How it works. Fourteen questions and two programs; 70% on the questions and both programs accepted clears the module.

Before you start, make sure you can answer:

  • Which classes are checked, which unchecked, and where Error sits.
  • What finally does to a pending return, and what a return inside finally does.
  • The order in which resources are closed and what happens to a close() exception.
  • Why you pass the cause when wrapping, and why you log once.
  • Why catch (Exception e) around business logic is dangerous.

The programs are a validating parser that reports every failure with a custom exception carrying data, and a resource-managed processor that proves close order and suppressed exceptions.

Common questions

Where does Error sit in the Java exception hierarchy?

Error is one of the two direct subclasses of Throwable, beside Exception. Like RuntimeException it is unchecked, but it signals failures of the JVM itself, such as OutOfMemoryError, which programs should not catch.

What does a return inside finally do to a pending exception?

It discards it. A return in finally replaces whatever the try or catch was about to do, so the method returns normally and the in-flight exception is lost without a trace.

What happens to an exception thrown by close() in try-with-resources?

If the body has already thrown, the close() exception is attached to the body's exception as a suppressed exception, and the body's exception propagates. If the body completed normally, the close() exception propagates itself.

Why is catching Exception around business logic dangerous?

It catches programming errors — a NullPointerException, a ClassCastException — along with the failures you meant to handle, so bugs look like transient problems and are retried or ignored instead of fixed.

Java Exceptions Quiz: Try, Catch and Finally Practice Test

Practise Java exceptions with 14 questions and two programs on checked and unchecked exceptions, finally, try-with-resources, custom exceptions and chaining.

  • Course: Java study plan
  • Module: Exceptions
  • Kind: Checkpoint — cleared at 70%
  • Reading time: 24 min
  • Runtime: OpenJDK 18

Checkpoint — Exceptions is the checkpoint that closes the Exceptions module: a graded quiz and whole-program exercises, passed at 70%.

Instructions

This checkpoint covers the exception hierarchy, checked versus unchecked, try/catch/finally semantics, try-with-resources, custom exceptions with chaining, and the handling practices.

How it works. Fourteen questions and two programs; 70% on the questions and both programs accepted clears the module.

Before you start, make sure you can answer:

  • Which classes are checked, which unchecked, and where Error sits.
  • What finally does to a pending return, and what a return inside finally does.
  • The order in which resources are closed and what happens to a close() exception.
  • Why you pass the cause when wrapping, and why you log once.
  • Why catch (Exception e) around business logic is dangerous.

The programs are a validating parser that reports every failure with a custom exception carrying data, and a resource-managed processor that proves close order and suppressed exceptions.

Common questions

Where does Error sit in the Java exception hierarchy?

Error is one of the two direct subclasses of Throwable, beside Exception. Like RuntimeException it is unchecked, but it signals failures of the JVM itself, such as OutOfMemoryError, which programs should not catch.

What does a return inside finally do to a pending exception?

It discards it. A return in finally replaces whatever the try or catch was about to do, so the method returns normally and the in-flight exception is lost without a trace.

What happens to an exception thrown by close() in try-with-resources?

If the body has already thrown, the close() exception is attached to the body's exception as a suppressed exception, and the body's exception propagates. If the body completed normally, the close() exception propagates itself.

Why is catching Exception around business logic dangerous?

It catches programming errors — a NullPointerException, a ClassCastException — along with the failures you meant to handle, so bugs look like transient problems and are retried or ignored instead of fixed.

Exercises

Config loader with layered exceptions

Write class ConfigException extends RuntimeException (message + cause). Write static int parsePort(String line) that expects port=<number>: for a line without = throw IllegalArgumentException("malformed: " + line); for a non-numeric value wrap the NumberFormatException in a ConfigException("bad port: " + value, e); for a port outside 1–65535 throw ConfigException("port out of range: " + n) with no cause.

Read an integer k and k lines. For each, print port=<n>, or config: <message> cause=<simple class of cause or none> for a ConfigException, or arg: <message> for an IllegalArgumentException. Catch the two types separately, most specific first.

Example: 4 then port=8080, port=abc, port=70000, nonsense →

port=8080
config: bad port: abc cause=NumberFormatException
config: port out of range: 70000 cause=none
arg: malformed: nonsense

Transaction with guaranteed rollback

Write class Tx implements AutoCloseable with a boolean committed; commit() sets it, and close() appends commit or rollback to a shared log depending on the flag. Read an integer n and n lines of commands: ok (body commits), fail (body throws IllegalStateException("failed") before committing), skip (body neither throws nor commits). Run each in try (Tx tx = new Tx()) { … }, catch the exception outside, and print <command>: <log entry> <caught message or -> per line.

Expected for ok fail skip:

ok: commit -
fail: rollback failed
skip: rollback -

A calculator that never crashes

Read expression lines <a> <op> <b> until end of input and evaluate each, turning every failure into a message: a non-integer operand → error: bad operand '<token>' (NumberFormatException); division or modulo by zero → error: division by zero (ArithmeticException); an unknown operator → error: unknown operator '<op>' (throw and catch your own UnknownOperatorException extends Exception); a line with fewer than three tokens → error: malformed line. Print results as <a> <op> <b> = <value>. Finish with ok=<count> errors=<count>.

Example input

6 * 7
1 / 0
2 ^ 3
x + 1

→

6 * 7 = 42
error: division by zero
error: unknown operator '^'
error: bad operand 'x'
ok=1 errors=3

In this module: Exceptions

← Exception handling that survives production · Why generics exist →