I realized it may still not be clear! Sorry, My dream Try would be something like this:
``` import static java.util.Try.on; import static java.util.Try.safe; private Bar convert (Foo foo) throws ConversionException { ... } Stream<Foo> foos; Stream<Bar> bars = foos.map(on(ConversionException.class)::of).map(safe(this::convert)).filter(Try::notInFailure).map(Try::get); ``` This is the algebra I would like to be able to write down! Basically, Try.on would return a monad of Try< . , ConversionException>, while the Try.safe method sanitizes a method: ``` @FunctionalInterface interface TryFunction<U,V, E extends Exception> { V apply(U args) throws E; } <U,V, E extends Exception> Function<U, Try<V, E>> safe (TryFunction<? super U, ? extends V, ? extends E> f) { ... } ``` The Try could be enriched with many interpolability facilities, but its essence would be to catch the provided exception. Best regards, Justin Dekeyser On Fri, May 8, 2020 at 1:23 AM Justin Dekeyser <justin.dekey...@gmail.com> wrote: > Dear Dmytro, > > Thank you very much for the time you have spent answering my email. > I am sorry if I was not clear in my previous sending. I will try to > elaborate. > > In my various situations, I find people that are convinced that checked > exceptions are too hard to manage, especially beacause it does not fit well > with streams and Optional. > > I think a Try class, as usually defined, may be a good utilitary class to > have in the java.utils library, in the same way Optional does. > > In my opinion, the covered feature is an enhancement, fills a gap in > functional style flow suggested by stream and optional, is business > agnostic, technology independant, figths against the anti pattern people > adopt by defining unchecked exceptions, so for all these reasons, I think > one can propose a solution as standard. > > Was the Try already discussed somewhere? What does Optional conceptually > brings, that Try could not? > > Best regards, > > Justin Dekeyser > > On Thursday, May 7, 2020, dmytro sheyko <dmytro.sheyko....@gmail.com> > wrote: > >> Hi Justin, >> >> This is not quite clear what exactly you are talking about. In any case >> why do you think it should be a part of OpenJDK? Can't it be just a >> separate library? >> >> Regards, >> Dmytro >> >> On Wed, May 6, 2020 at 8:31 AM Justin Dekeyser <justin.dekey...@gmail.com> >> wrote: >> >>> Hi everyone, >>> >>> I am new to the OpenJDK community and I'm using Java fora small decade >>> now, >>> first as a hobby, then in my academic studies and my PhD in maths, and >>> now >>> as a professional developer in IT companies. I'm quite active on forum to >>> help people, I've helped teaching students in the university, I read a >>> lot >>> of posts on blogs, and so many times I'm facing people having trouble >>> with >>> checked exceptions. >>> >>> The situation in my current job makes clarifies what I mean. People >>> usually >>> like declaring their own exception super class as "BusinessException", >>> then >>> deriving it in many subclasses to describe more accurate failure reasons. >>> The problem they face is that when they declare their class as *checked >>> Exception*, they cannot use the mechanism of Optional and Stream, for an >>> obvious reason. Usually they prefer Optional and Stream, so they end up >>> by >>> subclassing RuntimeException. >>> >>> I find it so sad because, when interfacing services, you often forget >>> about >>> declaring those unchecked exceptions, and the client is not aware of >>> what's >>> happening! I think you loose all the benefit of the exception mechanism >>> in >>> Java here for a very bad reason. >>> >>> In my job I finally rectified (partially, because the code base is huge) >>> the situation by implementing a "functional" Try in the same spirit than >>> the Optional. People are quite happy with it. I can invest more time in >>> its >>> development but I think this small library could help more people about >>> turning their exception in something clean again. So maybe it could be >>> useful for the whole community. (I already discussed it with my boss, >>> there >>> will be no copyright problem.) >>> >>> There exists similar projects around the world (in the Vavr lib for >>> example) and Scala offers this as a basic feature, which basically means >>> that people could appreciate the enhancement! >>> >>> I am wondering if the Try interface would be interesting for OpenJDK, if >>> they have been discussions about it, and what were the decisions about >>> such >>> a library? In my opinion, it may be a good complement to the Optional and >>> the Stream interfaces to allow a functional style while keeping this cool >>> feature of checked exceptions. >>> >>> Best regards, >>> >>> Justin Dekeyser >>> >>