Eclipse compiler incorrectly reports unhandled exceptions on lamba code

[xazap]

I get unhandled exception errors on code that uses Apache Commons Lang 3's Failable class. For easy reproduction I have put the lambas in a single class so it can be investigated without the Commons Lang dependency. The code below reproduces the issue on Eclipse 2023-12 (4.30.0) and in a Maven build using org.eclipse.jdt:ecj:3.36.0 as the compiler. Using Oracle's javac for Java 17 it compiles fine without errors.

There are 4 unhandled exceptions errors reported in the getFoobarClasses method even though the get() method catches these and rethrows them as RuntimeExceptions.

import java.nio.file.*;
import java.util.*;
import java.util.function.Function;
import java.util.stream.Collectors;

public class Foobar {
	@FunctionalInterface
	public interface FailableSupplier<T, E extends Throwable> {
		T get() throws E;
	}

	public static <T, E extends Throwable> T get(final FailableSupplier<T, E> supplier) {
		try {
			return supplier.get();
		} catch (final Throwable t) {
			throw new RuntimeException(t);
		}
	}

	@FunctionalInterface
	public interface FailableFunction<T, R, E extends Throwable> {
		R apply(T input) throws E;
	}

	public static <T, R, E extends Throwable> R apply(final FailableFunction<T, R, E> function, final T input) {
		return get(() -> function.apply(input));
	}

	public static <T, R> Function<T, R> asFunction(final FailableFunction<T, R, ?> function) {
		return input -> apply(function, input);
	}

	public static Set<Class<?>> getFoobarClasses(final String packageName, final ClassLoader classLoader) {
		return get(() -> {
			final var resourcePath = packageName.replace('.', '/');
			var resource = classLoader.getResource(resourcePath).toURI();
			FileSystem fileSystem = null;
			try {
				if ("jar".equals(resource.getScheme())) {
					fileSystem = FileSystems.newFileSystem(resource, Collections.emptyMap());
				}
				final var localPath = Paths.get(resource);
				return Files.list(localPath)
					.map(file -> file.getFileName().toString())
					.filter(filename -> filename.endsWith(".class"))
					.filter(filename -> !filename.contains("Foobar"))
					.map(asFunction(fileName -> {
						final var qualifiedClassName = packageName + '.' + fileName.substring(0, fileName.lastIndexOf(".class")).replace('/', '.');
						return (Class<?>) Class.forName(qualifiedClassName, false, classLoader);
					}))
					.collect(Collectors.toUnmodifiableSet());
			} finally {
				if (fileSystem != null) {
					fileSystem.close();
				}
			}
		});
	}
}

Have I run into a bug? Searching past issues it looks a bit like #1162 although no @SneakyThrows annotation is used in the code above.

[srikanth-sankaran]

I think this is the same problem as #1181 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=547231) for which a fix is available.

@stephan-herrmann - let us resurrect that discussion - It is sad/bad we reject code while trying to implement withdrawn stipulations of specification.

The reported problem goes away with the candidate fix

[stephan-herrmann]

I think this is the same problem as #1181 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=547231) for which a fix is available.

@stephan-herrmann - let us resurrect that discussion - It is sad/bad we reject code while trying to implement withdrawn stipulations of specification.

The reported problem goes away with the candidate fix

I'm sorry I dropped the ball in #1181. Definitely something we should resume. To be clear, my reluctance in #1181 is based on lack of understanding on my part not on actual doubts about the fix. I'll give it one more try to coerce the compiler into interesting code paths. If that doesn't give a clearer picture I'll just have to trust your reasoning (which sounded fine in the first place).

[srikanth-sankaran]

I have added the test case from here to the PR https://github.com/eclipse-jdt/eclipse.jdt.core/pull/1181created for #1169.

With that I will close this as a duplicate of #1169