Java's checked exceptions were a massive improvement over C's error-handling mechanism. As time passed and experience  accumulated, we collectively concluded that we weren't there yet. However, Java's focus on stability has kept checked exceptions in its existing API. Java 8 brought lambdas after the "checked exceptions are great"  trend. None of the functional interface methods accepts a checked exception. In this post, I will demonstrate three different approaches to making your legacy exception-throwing code compatible with lambdas. The problem, in code. Consider a simple exception-throwing method. public class Foo {
    public String throwing(String input) throws IOException {
        return input;                          //1
    }
} public class Foo {
    public String throwing(String input) throws IOException {
        return input;                          //1
    }
} The body is there for compilation purposes; its exact content is irrelevant. The body is there for compilation purposes; its exact content is irrelevant. The method accepts a String and returns a String. It has the shape of a Function<I, O>, so we can use it as such: String String Function<I, O> var foo = new Foo();
List.of("One", "Two").stream()
    .map(string -> foo.throwing(string))
    .toList(); var foo = new Foo();
List.of("One", "Two").stream()
    .map(string -> foo.throwing(string))
    .toList(); The above code fails with a compilation error: unreported exception IOException; must be caught or declared to be thrown
            .map(string -> foo.throwing(string)).toList();
                                       ^
1 error unreported exception IOException; must be caught or declared to be thrown
            .map(string -> foo.throwing(string)).toList();
                                       ^
1 error To fix the error, we need to wrap the throwing code in a try-catch block: List.of("One", "Two").stream()
    .map(string -> {
        try {
            return foo.throwing(string);
        } catch (IOException e) {
            return "";
        }
    }).toList(); List.of("One", "Two").stream()
    .map(string -> {
        try {
            return foo.throwing(string);
        } catch (IOException e) {
            return "";
        }
    }).toList(); At this point, the code compiles, but defeats the main purpose of lambdas: being concise and readable. A better approach. We can definitely improve the design by modeling a Function with a throwing apply(). Function apply() interface ThrowingFunction<I, O, E extends Exception> {
    O apply(I i) throws E;
} interface ThrowingFunction<I, O, E extends Exception> {
    O apply(I i) throws E;
} We can then provide a wrapper to transform such a throwing Function into a regular Function. Function Function class LambdaUtils {
    public static <I, O, E extends Exception> Function<I, O> safeApply(ThrowingFunction<I, O, E> f) {
        return input -> {
            try {
                return f.apply(input);
            } catch (Exception e) {
                return "";
            }
        };
    }
} class LambdaUtils {
    public static <I, O, E extends Exception> Function<I, O> safeApply(ThrowingFunction<I, O, E> f) {
        return input -> {
            try {
                return f.apply(input);
            } catch (Exception e) {
                return "";
            }
        };
    }
} With the above, the calling code can be improved like this: var foo = new Foo();
List.of("One", "Two").stream()
    .map(string -> LambdaUtils.safeApply(foo::throwing))     //1
    .toList(); var foo = new Foo();
List.of("One", "Two").stream()
    .map(string -> LambdaUtils.safeApply(foo::throwing))     //1
    .toList(); Concise code again Concise code again Libraries to the rescue. The most straightforward way to call exception-throwing code in a  lambda involves using a library. Two libraries that I know of provide  this capability: Apache Commons Lang 3
Vavr Apache Commons Lang 3 Apache Commons Lang 3 Vavr Vavr Here's how we can rewrite the above code using Commons Lang 3 code: var foo = new Foo();
FailableFunction<String, String, IOException> throwingFunction = foo::throwing; //1
List.of("One", "Two").stream()
    .map(throwingFunction)
    .recover(e -> "")                                                           //2
    .toList(); var foo = new Foo();
FailableFunction<String, String, IOException> throwingFunction = foo::throwing; //1
List.of("One", "Two").stream()
    .map(throwingFunction)
    .recover(e -> "")                                                           //2
    .toList(); Commons Lang 3 models a throwing Function
recover() mimics the value set in the previous catch block Commons Lang 3 models a throwing Function Function recover() mimics the value set in the previous catch block recover() catch The libraries improve upon my debatable design above, but the idea stays the same. The decision to roll out your own or use a library depends on a variety of factors that go beyond this post. Here are some criteria to help you. some criteria Suppressing Checked Exceptions Checked exceptions are a compile-time concern. The Java Language Specification states: A compiler for the Java programming language checks, at compile time, that a program contains handlers for checked exceptions,  by analyzing which checked exceptions can result from execution of a  method or constructor. For each checked exception which is a possible  result, the throws clause for the method (§8.4.6) or  constructor (§8.8.5) must mention the class of that exception or one of  the superclasses of the class of that exception. This compile-time  checking for the presence of exception handlers is designed to reduce  the number of exceptions which are not properly handled.
-- 11.2 Compile-Time Checking of Exceptions A compiler for the Java programming language checks, at compile time, that a program contains handlers for checked exceptions,  by analyzing which checked exceptions can result from execution of a  method or constructor. For each checked exception which is a possible  result, the throws clause for the method (§8.4.6) or  constructor (§8.8.5) must mention the class of that exception or one of  the superclasses of the class of that exception. This compile-time  checking for the presence of exception handlers is designed to reduce  the number of exceptions which are not properly handled. checked exceptions throws -- 11.2 Compile-Time Checking of Exceptions 11.2 Compile-Time Checking of Exceptions We could potentially hook into the compiler to prevent this check via a compiler plugin. Or find a library that does. That's when Manifold enters the scene. Manifold is a Java compiler plugin. Use it to supplement your Java projects with highly productive features.
Powerful language enhancements improve developer productivity.

Extension methods
True delegation
Properties
Optional parameters (New!)
Tuple expressions
Operator overloading
Unit expressions
A Java template engine
A preprocessor
...and more

-- What is Manifold Manifold is a Java compiler plugin. Use it to supplement your Java projects with highly productive features. Powerful language enhancements improve developer productivity. Extension methods
True delegation
Properties
Optional parameters (New!)
Tuple expressions
Operator overloading
Unit expressions
A Java template engine
A preprocessor
...and more Extension methods True delegation Properties Optional parameters (New!) Tuple expressions Operator overloading Unit expressions A Java template engine A preprocessor ...and more -- What is Manifold What is Manifold Disclaimer: I don't advocate for using Manifold. It makes the language you work with different from Java. At this point, you'd be  better off using Kotlin directly. Using Manifold to suppress checked exceptions is a two-step process. First, we add the Manifold runtime to the project: <dependency>
    <groupId>systems.manifold</groupId>
    <artifactId>manifold-rt</artifactId>
    <version>${manifold.version}</version>
    <scope>provided</scope>
</dependency> <dependency>
    <groupId>systems.manifold</groupId>
    <artifactId>manifold-rt</artifactId>
    <version>${manifold.version}</version>
    <scope>provided</scope>
</dependency> Then, we configure the compiler plugin: <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.0</version>
            <configuration>
                <source>11</source>
                <target>11</target>
                <encoding>UTF-8</encoding>
                <compilerArgs>
                    <arg>-Xplugin:Manifold</arg>
                </compilerArgs>
                <annotationProcessorPaths>
                    <path>
                        <groupId>systems.manifold</groupId>
                        <artifactId>manifold-exceptions</artifactId>
                        <version>${manifold.version}</version>
                    </path>
                </annotationProcessorPaths>
            </configuration>
        </plugin>
    </plugins>
</build> <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.0</version>
            <configuration>
                <source>11</source>
                <target>11</target>
                <encoding>UTF-8</encoding>
                <compilerArgs>
                    <arg>-Xplugin:Manifold</arg>
                </compilerArgs>
                <annotationProcessorPaths>
                    <path>
                        <groupId>systems.manifold</groupId>
                        <artifactId>manifold-exceptions</artifactId>
                        <version>${manifold.version}</version>
                    </path>
                </annotationProcessorPaths>
            </configuration>
        </plugin>
    </plugins>
</build> At this point, we can treat checked exceptions as unchecked. var foo = new Foo();
List.of("One", "Two").stream()
        .map(string -> foo.throwing(string))       //1
        .toList(); var foo = new Foo();
List.of("One", "Two").stream()
        .map(string -> foo.throwing(string))       //1
        .toList(); Compile with no issue Compile with no issue Conclusion In this post, I tackled the issue of integrating checked exceptions with lambdas in Java. I listed several options: the try-catch block, the throwing function, the library, and Manifold. I hope you can find one that suits your context among them. To go further: To go further: Apache Commons Lang 3
Vavr
Exceptions in Java Lambda Expressions
Exceptions in Lambda Expression Using Vavr
Say Goodbye to Checked Exceptions
Revisiting Resolving the Scourge of Java's Checked Exceptions Apache Commons Lang 3 Apache Commons Lang 3 Vavr Vavr Exceptions in Java Lambda Expressions Exceptions in Java Lambda Expressions Exceptions in Lambda Expression Using Vavr Exceptions in Lambda Expression Using Vavr Say Goodbye to Checked Exceptions Say Goodbye to Checked Exceptions Revisiting Resolving the Scourge of Java's Checked Exceptions Revisiting Resolving the Scourge of Java's Checked Exceptions Originally published at A Java Geek on January 18th, 2026 Originally published at A Java Geek on January 18th, 2026 A Java Geek

Apache

Transforming a JAR to a Full-Fledged macOS App

Moving From Cloudflare Zero-trust to Tailscale: The Pros and Cons

Read all my posts!

How to Make Your Legacy Exception-Throwing Code Compatible With Lambdas

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Essential Java Libraries - How Essential Are They Really?

Functional Programming With JavaScript: A Deep Dive

HSM: The Original Tiering Engine Behind Mainframes, Cloud, and S3

How to Add the AWS WAF CAPTCHA to an Angular Application

A Deeper Look at Exceptions in Java

A Simple Safety Net For Async EventHandlers

10 Essential Java Libraries - How Essential Are They Really?

Functional Programming With JavaScript: A Deep Dive

HSM: The Original Tiering Engine Behind Mainframes, Cloud, and S3

How to Add the AWS WAF CAPTCHA to an Angular Application

A Deeper Look at Exceptions in Java

A Simple Safety Net For Async EventHandlers

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps