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.