1. I think I got your point. It's not that the way I handle exceptions in the CompletableFuture is a "bad idea" is that using CompletableFuture itself is a bad idea. Well, it is a whole other topic. I have a couple of points about it, about why I even wrote this article. The first point is that I have some cases, not a lot though when I need to use CompletableFeature. I know that the best way is to use completely unblocking code like the Java Reactor project for example. But it is not always the case. If I have a system that already uses TomCat and I have to implement some parallel code I can't simply migrate to the Jetty and go reactive. The second point is that is good to learn a language in evolution. If one needs to learn reactive non-blocking code which looks like the future at the moment, one needs to know why the non-blocking code was discovered in the first place. The problem it tries to solve. I know that Spring and CompleatableFeature are not perfect, but it is still used.

2. I think the best way is to return the CompletableFeature from the method as you pointed out and from the method in the controller as well. Isn't it?

3. I use the principle of "baby steps" (one thing at a time) when I try to explain something I explain it in an "isolated way". I do agree with you that in this use case, var would be a better option, but to make it simple won't use var here.

Again thanks for your response.