Re: Was functional-Try already discussed?

2020-05-07 Thread 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 foos;
Stream 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 { V
apply(U args) throws E; }
 Function> safe (TryFunction 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 
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 
> 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 
>> 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
>>>
>>


Was functional-Try already discussed?

2020-05-05 Thread Justin Dekeyser
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