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

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Kafka Streams error handler code?

Consider the following Kafka Streams code snippet that uses a custom error handler. What will be printed when a deserialization error occurs?

Kafka

StreamsBuilder builder = new StreamsBuilder();

builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String())
    .withErrorHandler((context, exception) -> {
        System.out.println("Error in topic: " + context.topic());
        return DeserializationHandlerResponse.CONTINUE;
    }))
    .to("output-topic");

KafkaStreams streams = new KafkaStreams(builder.build(), new Properties());
// Assume a deserialization error occurs on "input-topic"

A Exception thrown and stream stopped

B Error in topic: input-topic

C No output printed, error ignored silently

D Error in topic: output-topic

💡 Hint

Think about what the error handler prints and which topic it refers to.

The error handler prints the topic where the error happened, which is the input topic. It then returns CONTINUE, so the stream continues running.

🧠 Conceptual

intermediate

Which error handling strategy stops the Kafka Streams application on error?

Kafka Streams offers different error handling strategies. Which one will cause the application to stop processing when an error occurs?

A Log and continue processing

B Ignore errors silently

C Fail fast and stop the application

D Retry indefinitely without stopping

💡 Hint

Consider which strategy prioritizes safety by stopping on errors.

The 'fail fast' strategy stops the Kafka Streams application immediately when an error occurs to avoid inconsistent state.

🔧 Debug

advanced

Identify the error in this Kafka Streams error handler configuration

Review the following Kafka Streams error handler setup. What is the error that will cause a runtime failure?

Kafka

StreamsBuilder builder = new StreamsBuilder();

builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String())
    .withErrorHandler((context, exception) -> {
        System.out.println("Error in topic: " + context.topic());
        return DeserializationHandlerResponse.FAIL;
    }))
    .to("output-topic");

KafkaStreams streams = new KafkaStreams(builder.build(), new Properties());
streams.start();

A The error handler returns FAIL but the stream is not closed properly, causing resource leaks

B The error handler lambda syntax is invalid, causing a compilation error

C The error handler returns an undefined enum value, causing a runtime exception

D The error handler does not handle exceptions, causing the stream to crash

💡 Hint

Think about what happens when FAIL is returned and how the stream lifecycle is managed.

Returning FAIL tells Kafka Streams to stop processing on error, but if the application does not close the stream properly, resources may leak.

📝 Syntax

advanced

Which option correctly configures a Kafka Streams error handler for deserialization errors?

Choose the code snippet that correctly sets a deserialization error handler in Kafka Streams.

A Consumed.with(Serdes.String(), Serdes.String()).withErrorHandler((context, ex) -> DeserializationHandlerResponse.CONTINUE);

B Consumed.with(Serdes.String(), Serdes.String()).withErrorHandler { context, ex -> DeserializationHandlerResponse.CONTINUE }

C Consumed.with(Serdes.String(), Serdes.String()).withErrorHandler((context, ex) -> { return DeserializationHandlerResponse.CONTINUE; });

D Consumed.with(Serdes.String(), Serdes.String()).withErrorHandler((context, ex) => DeserializationHandlerResponse.CONTINUE);

💡 Hint

Recall Java lambda syntax and method chaining style.

Option A uses correct Java lambda syntax and method chaining. Option A uses invalid syntax for Java. Option A misses a semicolon. Option A uses JavaScript arrow syntax, invalid in Java.

🚀 Application

expert

How many error handler invocations occur for a batch of 3 corrupted messages in Kafka Streams?

Assume a Kafka Streams application processes a batch of 3 messages, all corrupted causing deserialization errors. The error handler is set to CONTINUE after logging. How many times will the error handler be invoked?

A 1

B Depends on the number of partitions

C 0

D 3

💡 Hint

Think about how Kafka Streams processes each message and triggers error handlers.

The error handler is invoked once per corrupted message, so for 3 corrupted messages, it is called 3 times.

Practice

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

easy

A. To delete all bad data permanently

B. To keep the stream running smoothly even if some data is bad

C. To stop the stream immediately when an error occurs

D. To ignore errors and continue processing without any checks

Solution

1. Step 1: Understand error handling goal

   Error handling aims to manage problems without stopping the whole process.

2. Step 2: Identify correct purpose in Kafka streams

   Kafka streams use error handling to keep processing even if some data is bad.

3. Final Answer:

   To keep the stream running smoothly even if some data is bad -> Option B

4. Quick Check:

   Error handling = keep stream running [OK]

Hint: Error handling means keep running despite bad data [OK]

Common Mistakes:

• Thinking error handling stops the stream
• Assuming bad data is deleted automatically
• Ignoring the need to handle errors

2. Which syntax correctly shows how to catch exceptions in a Kafka Streams processor in Java?

easy

A. catch (Exception e) { processRecord(); } try { handleError(e); }

B. processRecord() catch Exception e handleError(e)

C. try { processRecord(); } catch (Exception e) { handleError(e); }

D. try processRecord() catch Exception handleError()

Solution

1. Step 1: Recall Java try-catch syntax

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

2. Step 2: Match correct syntax for Kafka Streams processor

   try { processRecord(); } catch (Exception e) { handleError(e); } correctly wraps processRecord() in try and catches Exception e to handle errors.

3. Final Answer:

   try { processRecord(); } catch (Exception e) { handleError(e); } -> Option C

4. Quick Check:

   Java try-catch syntax = try { processRecord(); } catch (Exception e) { handleError(e); } [OK]

Hint: Remember Java try-catch blocks use braces and catch after try [OK]

Common Mistakes:

• Placing catch before try
• Missing braces {} around try or catch blocks
• Using incorrect keywords or order

3. Given this Kafka Streams code snippet, what happens when a bad record causes an exception?

streams.foreach((key, value) -> {
  try {
    process(value);
  } catch (Exception e) {
    deadLetterTopic.send(key, value);
  }
});

medium

A. The exception crashes the whole application

B. The stream stops processing immediately

C. The bad record is ignored and lost

D. The bad record is sent to a dead-letter topic for later review

Solution

1. Step 1: Analyze try-catch block in code

   The code tries to process each record; if an exception occurs, it catches it.

2. Step 2: Check catch block action

   In catch, the bad record is sent to deadLetterTopic for later review.

3. Final Answer:

   The bad record is sent to a dead-letter topic for later review -> Option D

4. Quick Check:

   Exception caught = send to dead-letter topic [OK]

Hint: Catch exceptions and send bad data to dead-letter topic [OK]

Common Mistakes:

• Assuming stream stops on exception
• Thinking bad data is lost without handling
• Believing exception crashes app without catch

4. Identify the error in this Kafka Streams error handling code:

streams.foreach((key, value) -> {
  try {
    process(value);
  } catch Exception e {
    log.error(e.getMessage());
  }
});

medium

A. Missing parentheses around Exception e in catch block

B. Using foreach instead of map for error handling

C. Logging error message is incorrect

D. Try block should be outside the foreach

Solution

1. Step 1: Check catch block syntax

   In Java, catch must have parentheses around the exception type and variable.

2. Step 2: Identify missing parentheses

   The code has 'catch Exception e' missing parentheses; correct is 'catch (Exception e)'.

3. Final Answer:

   Missing parentheses around Exception e in catch block -> Option A

4. Quick Check:

   Catch syntax requires parentheses [OK]

Hint: Catch blocks always need parentheses around exception [OK]

Common Mistakes:

• Omitting parentheses in catch
• Confusing foreach and map usage
• Thinking logging method is wrong

5. You want to build a Kafka Streams application that processes user events but sends any malformed events to a separate topic without stopping the main stream. Which approach best achieves this?

hard

A. Use a try-catch inside the stream processor to send bad events to a dead-letter topic

B. Stop the stream when a malformed event is detected to fix data immediately

C. Ignore malformed events and continue processing without logging

D. Filter out malformed events before processing without saving them

Solution

1. Step 1: Understand requirement to keep stream running

   The stream must continue processing even if some events are bad.

2. Step 2: Choose method to handle bad events

   Using try-catch to catch errors and send bad events to a dead-letter topic allows this.

3. Final Answer:

   Use a try-catch inside the stream processor to send bad events to a dead-letter topic -> Option A

4. Quick Check:

   Try-catch + dead-letter topic = best error handling [OK]

Hint: Try-catch plus dead-letter topic keeps stream healthy [OK]

Common Mistakes:

• Stopping stream on error instead of handling
• Ignoring bad data without saving for review
• Filtering bad data without storing it