Error handling in clients in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output when a Kafka consumer encounters a deserialization error?

Consider a Kafka consumer configured with a custom deserializer that throws an exception on invalid data. What will the consumer do when it reads a corrupted message?

Kafka

try {
  ConsumerRecord<String, String> record = consumer.poll(Duration.ofMillis(100)).iterator().next();
  String value = record.value(); // Custom deserializer may throw here
  System.out.println("Received: " + value);
} catch (SerializationException e) {
  System.out.println("Deserialization error caught");
}

A Prints "Deserialization error caught" when a corrupted message is read

B Throws an uncaught exception and stops the consumer

C Prints "Received: <message>" for all messages, including corrupted ones

D Skips corrupted messages silently without any output

💡 Hint

Think about how exceptions in deserialization are handled inside the try-catch block.

When the custom deserializer throws a SerializationException during poll(), the catch block catches it and prints the error message. This prevents the consumer from crashing and allows handling of corrupted messages.

❓ Predict Output

intermediate

What happens if a Kafka producer's send callback reports a network error?

A Kafka producer sends a message asynchronously with a callback that checks for exceptions. What will the callback print if the network is down during send?

Kafka

producer.send(new ProducerRecord<>("topic", "key", "value"), (metadata, exception) -> {
  if (exception != null) {
    System.out.println("Send failed: " + exception.getClass().getSimpleName());
  } else {
    System.out.println("Send succeeded");
  }
});

A Prints "Send failed: TimeoutException" or a related network error

B Does not print anything because callback is not called

C Throws an exception outside the callback

D Prints "Send succeeded" even if network is down

💡 Hint

The callback receives an exception parameter when send fails.

If the network is down, the send operation fails and the callback receives an exception such as TimeoutException. The callback prints the failure message with the exception type.

🧠 Conceptual

advanced

Which error handling strategy prevents message loss in Kafka consumers?

You want to ensure no messages are lost even if processing fails. Which approach is best for error handling in Kafka consumers?

A Use auto-commit with a short interval

B Commit offsets immediately after polling messages

C Ignore exceptions and continue processing next messages

D Commit offsets only after successful processing of messages

💡 Hint

Think about when to commit offsets to avoid losing unprocessed messages.

Committing offsets only after successful processing ensures that if processing fails, the consumer will re-read the message on restart, preventing message loss.

❓ Predict Output

advanced

What error does this Kafka consumer code raise?

Analyze the following Kafka consumer code snippet and identify the error it raises at runtime.

Kafka

consumer.subscribe(Collections.singletonList("topic"));
while (true) {
  ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
  for (ConsumerRecord<String, String> record : records) {
    System.out.println(record.value().toUpperCase());
  }
  consumer.commitSync();
}
consumer.close();

A IllegalStateException because consumer.close() is unreachable

B NoSuchElementException when records is empty

C No error, prints all messages in uppercase

D CommitFailedException if commitSync is called without subscription

💡 Hint

Consider the code flow and whether it raises a runtime exception.

The consumer.close() line is unreachable due to the infinite while(true) loop, causing a compiler warning but no runtime error. At runtime, the code polls records, prints their values in uppercase using a for-each loop (which handles empty records safely), commits offsets with commitSync(), and continues indefinitely without throwing any exception.

🧠 Conceptual

expert

How to handle poison pill messages in Kafka consumers to avoid infinite processing loops?

A poison pill message causes your consumer to fail processing repeatedly. What is the best error handling approach to avoid infinite retries on such messages?

A Skip the message by committing the offset and log the error

B Use a dead-letter queue to move poison pill messages after retries

C Stop the consumer immediately on first failure

D Ignore errors and keep retrying indefinitely

💡 Hint

Think about how to isolate bad messages without losing them.

Using a dead-letter queue allows the consumer to move poison pill messages after a number of retries, preventing infinite loops while preserving the messages for later inspection.

Practice

1. What is the main purpose of error handling in Kafka clients?

easy

A. To increase the speed of message processing

B. To keep the client stable and responsive during failures

C. To reduce the size of messages sent

D. To automatically create Kafka topics

Solution

1. Step 1: Understand error handling role

   Error handling helps the client manage unexpected problems without crashing.

2. Step 2: Identify the main goal in Kafka clients

   Keeping the client stable and responsive ensures smooth operation even if errors occur.

3. Final Answer:

   To keep the client stable and responsive during failures -> Option B

4. Quick Check:

   Error handling = stability and responsiveness [OK]

Hint: Error handling keeps your client stable and responsive [OK]

Common Mistakes:

• Thinking error handling speeds up processing
• Confusing error handling with message size control
• Assuming error handling creates topics automatically

2. Which syntax correctly wraps a Kafka producer send call to catch exceptions in Java?

easy

A. producer.send(record).catch(e => console.log(e));

B. if (producer.send(record)) { } else { handleError(); }

C. try { producer.send(record); } catch (Exception e) { e.printStackTrace(); }

D. try catch producer.send(record);

Solution

1. Step 1: Identify correct Java try-catch syntax

   Java requires try { ... } catch (Exception e) { ... } to handle exceptions.

2. Step 2: Match syntax with Kafka producer send call

   try { producer.send(record); } catch (Exception e) { e.printStackTrace(); } correctly wraps the send call in try-catch block.

3. Final Answer:

   try { producer.send(record); } catch (Exception e) { e.printStackTrace(); } -> Option C

4. Quick Check:

   Java try-catch syntax = try { producer.send(record); } catch (Exception e) { e.printStackTrace(); } [OK]

Hint: Use try-catch blocks in Java to catch Kafka errors [OK]

Common Mistakes:

• Using if-else instead of try-catch for exceptions
• Using JavaScript syntax in Java code
• Missing braces in try-catch block

3. Given this Java Kafka consumer code snippet, what will be printed if a network error occurs during poll?

try {
  ConsumerRecords records = consumer.poll(Duration.ofMillis(100));
  for (var record : records) {
    System.out.println(record.value());
  }
} catch (WakeupException e) {
  System.out.println("Consumer interrupted");
} catch (Exception e) {
  System.out.println("Error during poll");
}

medium

A. Error during poll

B. Consumer interrupted

C. No output

D. Exception stack trace

Solution

1. Step 1: Identify exception types caught

   WakeupException prints "Consumer interrupted"; all other exceptions print "Error during poll".

2. Step 2: Determine exception for network error

   Network errors throw general exceptions, not WakeupException.

3. Final Answer:

   Error during poll -> Option A

4. Quick Check:

   Network error triggers general Exception = Error during poll [OK]

Hint: General exceptions print "Error during poll" [OK]

Common Mistakes:

• Confusing WakeupException with network errors
• Expecting no output on error
• Assuming stack trace prints automatically

4. Identify the error in this Kafka producer error handling code snippet:

try {
  producer.send(record);
} catch (KafkaException e) {
  System.out.println("Error sending message");
}
producer.close();

medium

A. producer.send() does not throw exceptions

B. Catch block should catch Exception, not KafkaException

C. Missing return statement after catch

D. producer.close() should be inside finally block

Solution

1. Step 1: Check resource cleanup

   producer.close() must run regardless of exceptions to free resources.

2. Step 2: Use finally block for cleanup

   Placing close() inside finally ensures it always executes.

3. Final Answer:

   producer.close() should be inside finally block -> Option D

4. Quick Check:

   Always close resources in finally block [OK]

Hint: Put cleanup code in finally block to always run [OK]

Common Mistakes:

• Closing producer only on success
• Catching too broad or wrong exceptions
• Assuming send() never throws exceptions

5. You want to build a Kafka consumer that retries polling up to 3 times on recoverable errors, then logs and stops. Which approach correctly implements this error handling?

hard

A. Use a loop with try-catch around poll; on exception increment retry count; break after 3 retries; finally close consumer

B. Call consumer.poll() once; if exception, immediately close consumer without retry

C. Wrap poll in try-catch but ignore exceptions and continue polling forever

D. Use multiple nested try-catch blocks without retry logic

Solution

1. Step 1: Understand retry logic requirements

   Retry polling up to 3 times on recoverable errors, then stop and log.

2. Step 2: Identify correct control flow

   Loop with try-catch, count retries, break after 3 attempts, and close consumer in finally block is correct.

3. Final Answer:

   Use a loop with try-catch around poll; on exception increment retry count; break after 3 retries; finally close consumer -> Option A

4. Quick Check:

   Retry with loop and try-catch = Use a loop with try-catch around poll; on exception increment retry count; break after 3 retries; finally close consumer [OK]

Hint: Use loop with try-catch and retry count for controlled retries [OK]

Common Mistakes:

• Not retrying on recoverable errors
• Ignoring exceptions and continuing endlessly
• Closing consumer too early without retries