Was functional-Try already discussed?

[Justin Dekeyser]

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.dekeyser at 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.jdk at 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.dekeyser at 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
>>>
>>