Java Custom Exceptions & Exception Hierarchy Quiz
30 in-depth questions (15 with code) covering creating custom exceptions, throw vs throws, checked vs unchecked exceptions, chained exceptions, and designing exception structures in Java.
30 Questions
~60 minutes
1
Question 1
When should you create a custom exception class?
A
When you need to represent application-specific error conditions that aren't covered by standard exceptions
B
Always, instead of using built-in exceptions
C
Never, built-in exceptions are sufficient
D
Only for checked exceptions
2
Question 2
What is the difference between 'throw' and 'throws'?
A
'throw' throws an exception object, 'throws' declares that a method might throw exceptions
B
They are synonyms
C
'throw' is for checked exceptions only
D
'throws' creates new exceptions
3
Question 3
What is a checked exception?
A
Exceptions that must be either caught or declared in method signatures
B
Exceptions that occur at runtime only
C
Exceptions that are automatically handled
D
Exceptions that cannot be caught
4
Question 4
What is an unchecked exception?
A
Runtime exceptions and errors that don't require explicit handling
B
Exceptions that are checked at compile-time
C
Exceptions that must be caught
D
Exceptions from external libraries
5
Question 5
What is exception chaining?
A
Wrapping one exception inside another to preserve the original cause
B
Catching multiple exceptions in sequence
C
Throwing exceptions from finally blocks
D
Using multiple catch blocks
6
Question 6
How do you create a custom checked exception?
java
public class CustomCheckedException extends Exception {
public CustomCheckedException(String message) {
super(message);
}
public CustomCheckedException(String message, Throwable cause) {
super(message, cause);
}
}A
Extend Exception class with appropriate constructors
B
Extend RuntimeException
C
Extend Error
D
Use throw keyword
7
Question 7
How do you create a custom unchecked exception?
java
public class CustomUncheckedException extends RuntimeException {
public CustomUncheckedException(String message) {
super(message);
}
public CustomUncheckedException(String message, Throwable cause) {
super(message, cause);
}
}A
Extend RuntimeException class with appropriate constructors
B
Extend Exception
C
Extend Error
D
Use throws keyword
8
Question 8
What is the purpose of the cause parameter in exception constructors?
A
To chain exceptions and preserve the original error that caused the current exception
B
To specify the exception type
C
To set the exception message
D
To determine if it's checked or unchecked
9
Question 9
When should you use checked exceptions in your API design?
A
For recoverable error conditions that callers should be forced to handle
B
For all exceptions
C
Never, use unchecked exceptions
D
Only in private methods
10
Question 10
When should you use unchecked exceptions in your API design?
A
For programming errors and unexpected conditions that callers cannot reasonably handle
B
For all exceptions
C
For recoverable errors
D
Only in public APIs
11
Question 11
What is the result of this custom exception creation?
java
public class ValidationException extends Exception {
private String fieldName;
public ValidationException(String fieldName, String message) {
super(message);
this.fieldName = fieldName;
}
public String getFieldName() {
return fieldName;
}
}
// Usage:
try {
throw new ValidationException("email", "Invalid email format");
} catch (ValidationException e) {
System.out.println("Field: " + e.getFieldName() + ", Error: " + e.getMessage());
}A
Field: email, Error: Invalid email format
B
Compilation error
C
Runtime exception
D
No output
12
Question 12
What is wrong with this exception hierarchy design?
java
public class DatabaseException extends Exception {
// Generic database exception
}
public class ConnectionException extends DatabaseException {
// Connection problems
}
public class QueryException extends DatabaseException {
// Query execution problems
}
public class TimeoutException extends ConnectionException {
// Connection timeout
}A
Nothing, this is a good exception hierarchy
B
TimeoutException should extend DatabaseException directly
C
Should use RuntimeException instead
D
Missing constructors
13
Question 13
How do you properly chain exceptions?
java
try {
// Some operation that might fail
riskyOperation();
} catch (SQLException e) {
throw new CustomBusinessException("Business operation failed", e);
}A
Pass the original exception as the cause parameter
B
Replace the original exception completely
C
Log the original and throw a new one without cause
D
Catch the original and ignore it
14
Question 14
What is the output of this exception chaining example?
java
public class CustomException extends Exception {
public CustomException(String message, Throwable cause) {
super(message, cause);
}
}
public class Test {
public static void main(String[] args) {
try {
try {
throw new RuntimeException("Original error");
} catch (RuntimeException e) {
throw new CustomException("Wrapped error", e);
}
} catch (CustomException e) {
System.out.println("Message: " + e.getMessage());
System.out.println("Cause: " + e.getCause().getMessage());
}
}
}A
Message: Wrapped error
Cause: Original error
B
Message: Original error
C
Compilation error
D
Runtime exception
15
Question 15
Why should custom exceptions follow naming conventions?
A
To clearly indicate they are exceptions and follow Java conventions
B
To make them compile faster
C
To avoid naming conflicts
D
It doesn't matter
16
Question 16
What is the problem with this custom exception?
java
public class MyException extends RuntimeException {
public MyException() {
// No message or cause
}
}A
It doesn't provide useful error information
B
It extends the wrong class
C
It should be checked
D
No problem, it's fine
17
Question 17
How should you design exception hierarchies for a library?
A
Create a base exception class for the library, with specific subclasses for different error types
B
Use only built-in exceptions
C
Create one exception class for everything
D
Use unchecked exceptions only
18
Question 18
What is the result of this throws declaration?
java
public void processData() throws CustomCheckedException {
if (dataInvalid) {
throw new CustomCheckedException("Data validation failed");
}
}A
Callers must handle CustomCheckedException
B
Callers can ignore the exception
C
Compilation error
D
Runtime exception
19
Question 19
Why should you avoid creating too many custom exception types?
A
It can make APIs complex and hard to use
B
It slows down the JVM
C
It prevents compilation
D
It should be avoided completely
20
Question 20
What is the output of this exception hierarchy example?
java
class BaseException extends Exception {
BaseException(String msg) { super(msg); }
}
class SpecificException extends BaseException {
SpecificException(String msg) { super(msg); }
}
public class Test {
static void method() throws BaseException {
throw new SpecificException("Specific error");
}
public static void main(String[] args) {
try {
method();
} catch (BaseException e) {
System.out.println("Caught: " + e.getClass().getSimpleName());
}
}
}A
Caught: SpecificException
B
Caught: BaseException
C
Compilation error
D
Runtime exception
21
Question 21
How do you create an exception with additional context?
java
public class ValidationException extends Exception {
private final String field;
private final Object invalidValue;
public ValidationException(String field, Object invalidValue, String message) {
super(message);
this.field = field;
this.invalidValue = invalidValue;
}
// getters...
}A
Add fields and constructors to store additional information
B
Use only the message
C
Extend RuntimeException
D
Use static methods
22
Question 22
What is wrong with throwing built-in exceptions for custom errors?
A
It doesn't provide specific error information to callers
B
It makes code faster
C
It prevents inheritance
D
Nothing, it's fine
23
Question 23
How should you handle exceptions when wrapping third-party libraries?
A
Wrap third-party exceptions in your custom exceptions to hide implementation details
B
Let third-party exceptions propagate unchanged
C
Convert all to RuntimeException
D
Ignore them
24
Question 24
What is the result of this chained exception access?
java
try {
throw new RuntimeException("Root cause");
} catch (RuntimeException e) {
CustomException ce = new CustomException("Wrapper message", e);
System.out.println("Wrapper: " + ce.getMessage());
System.out.println("Cause: " + ce.getCause().getMessage());
}A
Wrapper: Wrapper message
Cause: Root cause
B
Wrapper: Root cause
C
Compilation error
D
Runtime exception
25
Question 25
When should you make custom exceptions serializable?
A
When exceptions might be sent across network boundaries or persisted
B
Always
C
Never
D
Only for checked exceptions
26
Question 26
What is the problem with this exception design?
java
public class MyLibraryException extends Exception {
public MyLibraryException(String msg) { super(msg); }
}
public class MySpecificException extends MyLibraryException {
public MySpecificException(String msg) { super(msg); }
}
// But MySpecificException is thrown from places where MyLibraryException is declaredA
The hierarchy is fine, but method signatures should declare the more specific type when possible
B
Should not extend MyLibraryException
C
Should use RuntimeException
D
No problem
27
Question 27
Why should exception messages be meaningful?
A
They help developers understand and fix problems quickly
B
They make the code run faster
C
They are required for compilation
D
They prevent exceptions
28
Question 28
What is the output of this throws vs throw example?
java
public class Test {
static void method1() throws CustomException {
throw new CustomException("Error from method1");
}
static void method2() {
try {
method1();
} catch (CustomException e) {
throw e; // re-throwing
}
}
public static void main(String[] args) {
try {
method2();
} catch (CustomException e) {
System.out.println("Caught: " + e.getMessage());
}
}
}A
Caught: Error from method1
B
Compilation error
C
Runtime exception
D
No output
29
Question 29
How do you design exceptions for different layers of an application?
A
Each layer translates lower-level exceptions to layer-appropriate exceptions
B
All layers use the same exceptions
C
Only the top layer handles exceptions
D
Ignore exceptions in lower layers
30
Question 30
Mastering custom exceptions means you now design APIs that:
A
Communicate errors clearly through well-designed exception hierarchies, preserve error context with chaining, and guide proper error handling with checked vs unchecked decisions
B
Never throw exceptions
C
Use only built-in exceptions
D
Catch all exceptions immediately