coderain blog

AWS Lambda Void Output: Using EventHandler as Alternative to RequestHandler in Java (No Return Value Needed)

AWS Lambda has revolutionized serverless computing by allowing developers to run code without provisioning or managing servers. In Java, Lambda functions typically use handlers to process events, with RequestHandler being the most common interface. However, many Lambda use cases—such as event processing, logging, or triggering downstream services—don’t require a return value. Using RequestHandler here can feel clunky, as it mandates a return type (even if you only return null).

In this blog, we’ll explore EventHandler, a lesser-known but powerful alternative in the AWS Lambda Java SDK designed explicitly for void-output scenarios. We’ll compare it with RequestHandler, walk through a step-by-step implementation, and discuss best practices to help you simplify your code when no return value is needed.

2026-01

Table of Contents#

  1. Understanding AWS Lambda Handlers in Java
  2. Introducing EventHandler: The Void-Friendly Alternative
  3. Step-by-Step Implementation: Using EventHandler for Void Output
  4. Use Cases for EventHandler
  5. Best Practices and Considerations
  6. Conclusion
  7. References

Understanding AWS Lambda Handlers in Java#

At the core of every AWS Lambda function is a handler—a method that processes incoming events and returns a response (or not). In Java, AWS provides two primary handler interfaces: RequestHandler and EventHandler. Let’s start by examining RequestHandler, the de facto standard.

RequestHandler: The Standard Approach#

RequestHandler is a generic interface defined in the AWS Lambda Java SDK. It requires implementing a handleRequest method that takes an input object and a Context object, and returns an output object. The signature is:

public interface RequestHandler<T, R> {
    R handleRequest(T input, Context context);
}

Example: RequestHandler with a Return Value
Suppose you have a Lambda that processes a string input and returns a formatted response. Here’s how you’d implement it with RequestHandler:

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
 
public class StringProcessor implements RequestHandler<String, String> {
    @Override
    public String handleRequest(String input, Context context) {
        String processed = "Processed: " + input.toUpperCase();
        context.getLogger().log("Processed input: " + processed);
        return processed; // Return value required
    }
}

This works well when you need to return data (e.g., an API Gateway response). But what if your Lambda doesn’t need a return value?

When RequestHandler Feels Unnecessary: The Void Output Scenario#

Many Lambda functions are designed for processing-only workflows—for example:

  • Logging event details to CloudWatch.
  • Processing an S3 event to resize images (no response needed).
  • Forwarding messages from SQS to another service (fire-and-forget).

In these cases, RequestHandler forces you to define a return type. The workaround is to use Void as the output type, but this leads to clunky code:

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
 
// Clunky: Using Void as the return type
public class EventLogger implements RequestHandler<String, Void> {
    @Override
    public Void handleRequest(String input, Context context) {
        context.getLogger().log("Received event: " + input);
        return null; // Dummy return value (required but unused)
    }
}

Here, return null is a necessary evil—RequestHandler demands a return value, even if it’s never used. This is where EventHandler shines.

Introducing EventHandler: The Void-Friendly Alternative#

EventHandler is a lightweight, functional interface introduced in the AWS Lambda Java SDK specifically for scenarios where no return value is needed. It eliminates the need for dummy return types, simplifying your code.

What is EventHandler?#

EventHandler is defined as:

@FunctionalInterface
public interface EventHandler<T> {
    void handleRequest(T input, Context context);
}

Key features:

  • No return value: The handleRequest method returns void, so you avoid dummy return null statements.
  • Functional interface: Can be implemented with a lambda (though class-based implementations are more common for readability).
  • Simpler code: Focuses solely on processing the input, making intent clearer.

Key Differences Between EventHandler and RequestHandler#

FeatureRequestHandler<T, R>EventHandler<T>
Return TypeRequires an output type RNo return type (void)
Use CaseNeed to return a responseNo response needed (processing-only)
Method SignatureR handleRequest(T input, Context)void handleRequest(T input, Context)
Clarity for Void WorkflowsClunky (requires Void + return null)Clean (explicitly void)

Step-by-Step Implementation: Using EventHandler for Void Output#

Let’s walk through building a Lambda function with EventHandler to process SQS messages (a common void-output scenario).

Prerequisites#

  • Java 8 or later (Lambda supports up to Java 17).
  • Apache Maven (for dependency management and building the JAR).
  • AWS CLI configured with permissions to deploy Lambdas.
  • An AWS account with access to Lambda and SQS.

Setting Up the Project#

  1. Create a Maven Project
    Use mvn archetype:generate to create a basic Java project, or manually set up a pom.xml with the following dependencies:

    <dependencies>
    <!-- AWS Lambda Core (includes EventHandler) -->
    <dependency>
        <groupId>com.amazonaws</groupId>
        <artifactId>aws-lambda-java-core</artifactId>
        <version>1.2.2</version>
    </dependency>
    <!-- AWS Lambda Events (for SQS, S3, etc., event types) -->
    <dependency>
        <groupId>com.amazonaws</groupId>
        <artifactId>aws-lambda-java-events</artifactId>
        <version>3.11.0</version>
    </dependency>
</dependencies>
 
<!-- Build configuration to package as a shaded JAR -->
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>3.4.1</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>shade</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Creating the Lambda Function with EventHandler#

We’ll build a Lambda that processes SQSEvent messages (from Amazon SQS) and logs their content—no return value needed.

Code Implementation:

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.EventHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
 
public class SQSMessageProcessor implements EventHandler<SQSEvent> {
 
    @Override
    public void handleRequest(SQSEvent input, Context context) {
        // Log Lambda context details
        context.getLogger().log("Lambda Request ID: " + context.getAwsRequestId());
        
        // Process each SQS message
        for (SQSEvent.SQSMessage message : input.getRecords()) {
            String messageBody = message.getBody();
            String messageId = message.getMessageId();
            
            // Log message details (replace with your logic)
            context.getLogger().log("Processing SQS Message ID: " + messageId);
            context.getLogger().log("Message Body: " + messageBody);
            
            // Add your processing logic here (e.g., validate, transform, forward)
        }
    }
}

Key Details:

  • SQSEvent (from aws-lambda-java-events) is the input type, representing an SQS event with multiple records.
  • handleRequest has no return statement—focused solely on processing.
  • context.getLogger().log() writes to CloudWatch Logs (preferred over System.out).

Handling Input Events#

EventHandler supports any input type T, including:

  • Primitive types (String, Integer).
  • AWS event types (SQSEvent, S3Event, SNSEvent from aws-lambda-java-events).
  • Custom POJOs (for JSON input, Lambda automatically deserializes JSON to your POJO).

Example: Custom POJO Input
If your Lambda receives JSON input like {"id": 1, "data": "test"}, define a POJO:

public class CustomEvent {
    private int id;
    private String data;
    // Getters and setters
}

Then use it with EventHandler:

public class CustomEventProcessor implements EventHandler<CustomEvent> {
    @Override
    public void handleRequest(CustomEvent input, Context context) {
        context.getLogger().log("Processing event ID: " + input.getId());
    }
}

Building and Deploying the Lambda#

  1. Build the JAR
    Run mvn clean package to generate a shaded JAR in target/ (e.g., lambda-eventhandler-demo-1.0-SNAPSHOT.jar).

  2. Deploy via AWS CLI
    Use the AWS CLI to create or update the Lambda function:

    aws lambda create-function \
    --function-name SQSMessageProcessor \
    --runtime java11 \
    --role arn:aws:iam::ACCOUNT_ID:role/lambda-execution-role \
    --handler com.example.SQSMessageProcessor::handleRequest \
    --zip-file fileb://target/lambda-eventhandler-demo-1.0-SNAPSHOT.jar
    • Replace ACCOUNT_ID with your AWS account ID.
    • lambda-execution-role must have permissions to read SQS and write to CloudWatch Logs.

  3. Test the Lambda
    Trigger the Lambda by sending a message to your SQS queue. Check CloudWatch Logs to verify processing.

Use Cases for EventHandler#

EventHandler is ideal for processing-centric workflows where no response is needed. Common use cases include:

1. Logging and Monitoring#

Process events (e.g., API Gateway, S3) and log metadata (timestamps, user IDs) to CloudWatch for auditing.

2. Event Processing Pipelines#

  • Resize images from S3 events (no return needed—just store the resized image).
  • Filter or transform messages in SQS before forwarding to another service.

3. Fire-and-Forget Actions#

  • Asynchronously trigger downstream services (e.g., send a notification via SNS, invoke another Lambda).
  • Batch-process records from DynamoDB Streams without returning results.

Best Practices and Considerations#

1. Error Handling#

Since there’s no return value, errors must be logged or propagated:

  • Use try-catch blocks to handle exceptions and log details.

  • Let uncaught exceptions bubble up to Lambda—this triggers retries (for event sources like SQS) and marks the invocation as failed in CloudWatch.

    @Override
public void handleRequest(SQSEvent input, Context context) {
    try {
        // Processing logic
    } catch (Exception e) {
        context.getLogger().log("Error processing event: " + e.getMessage());
        throw e; // Trigger retry/error reporting
    }
}

2. Logging#

Always log input, processing steps, and errors for debugging. Use context.getLogger() for CloudWatch integration.

3. Input Validation#

Even without a return value, validate inputs to avoid processing invalid data:

if (input.getRecords() == null || input.getRecords().isEmpty()) {
    context.getLogger().log("No records to process");
    return;
}

4. Cold Starts#

EventHandler functions have the same cold start behavior as RequestHandler—minimize dependencies to reduce startup time.

Conclusion#

EventHandler is a powerful alternative to RequestHandler for AWS Lambda functions in Java when no return value is needed. It simplifies code by eliminating dummy return statements, clarifies intent, and works seamlessly with processing-centric workflows like logging, event pipelines, and fire-and-forget actions.

By adopting EventHandler, you’ll write cleaner, more maintainable code tailored to void-output scenarios. Next time you build a Lambda that doesn’t need to return data, give EventHandler a try!

References#