jasongoodwin / better-java-monads Goto Github PK

Not sure why, but the published pom has a dependency on scala-library. See https://repo1.maven.org/maven2/com/jason-goodwin/better-monads/0.4.0/better-monads-0.4.0.pom. The dependency can be excluded without impact, but it should be removed if it is not needed.

I'm having problems getting compile/publish to work with the javadoc.
I thought I had solved this but I'm seeing the same issue again.

first of all thanks for your perfect try-monad, i enjoy it very much.

using jetty i've got such worning:
2016-08-22 11:34:51.474:WARN:oeja.AnnotationParser:main: EXCEPTION
java.lang.ArrayIndexOutOfBoundsException: 5160
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:910)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:773)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:766)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:766)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:766)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:766)
...
2016-08-22 11:34:53.274:WARN:oeja.AnnotationParser:main: Problem processing jar entry com/jasongoodwin/monads/Futures.class
java.lang.ArrayIndexOutOfBoundsException: 3145
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
...

in spite of the worning project works well, but it would be nice fix it in next versions. thanks

travis should be used in this project.

I couldn't find a way to get the exception from a failed try.

I was expecting to see something like
Optional<RuntimeException> exception = Try.offFailable( ()-> throw new RuntimeException("a") ).getException()

I suggest adding orElseThrow() method that could be used to translate the thrown exception into an exception of your own choice.

What do you think?

I noticed the other day the scala Future traverse method. It's similar to sequence, but does it all in one step.
Something like this.

Future<List<Item>> future = Futures.traverse(collection, x -> doAsync(x))

Scala has TraversableOnce trait (eg extended by AbstractSeq) but could just make one for List in java. This seems like a nice option instead of doing

Futures.sequence(list.sequence.map(x -> doAsync(x).collect(Collectors.toList()));

These take consumer functions as arguments and so the API is not explicit enough in returning the try again.
It looks nice chaining the effects together but I don't believe that the Try should be returned in these cases as it is not (and cannot) be mutated.

I have an existing async called wrapped inside a Try and working with Futures.sequence

e.g.

List<CompletableFuture<Try<Foo>>> requests = [...]
CompletableFuture<List<Try<Baz>>> items = Futures.sequence(requests);
List<Try<Baz>> result = items.join()
.stream()
.map(try -> myFunction(try))
.collect(Collectors.toList())

...

private Try<Baz> myFunction(Try<Foo> fooTry) {
    return fooTry.flatMap(foo -> Try.ofFailable(() -> process(foo)));
}

is there an example/support for two async calls? such as

List<CompletableFuture<Try<Foo>>> requests1 = [...]
List<CompletableFuture<Try<Bar>>> requests2 = [...]
// requests1.size(), requests2.size() are the same value
List<CompletableFuture<Try<Baz>>> results = new ArrayList<>();
for (int i = 0; i < items1.size(); i++) {
    CompletableFuture<Try<Baz>> combined = items1.get(i).thenCombine(items2.get(i), (fooTry, barTry) -> myFunction(fooTry, barTry));
    results.add(combined);
}

List<Try<Baz>> results = results.stream().map(CompletableFuture::join).collect(Collectors.toList());
...

private Try<Baz> myFunction(Try<Foo> fooTry, Try<Bar> barTry) {
    return fooTry.flatMap(foo -> barTry.flatMap(bar -> Try.ofFailable(() -> process(foo, bar))));
}

Hi,

first of all thanks a lot for such an important monads implementation! I do have a question though: you made your Success and Failure classes as package local so that it gives no opportunity to "pattern match" (using java's instanceOf). I do see that your API is inspired by scala but unfortunately with a good encapsulation you sacrificed the ability to match and therefore get the actual exception from Failure.

Can it be changed or you would like to keep it as it is? Otherwise I would be more than glad to provide a pull request.

I noticed you created a set of 3 functional types with signatures that support throwing Throwables.
I have my own project that already defined a complete set of functional types that support throwing Throwables. I think it might be worth considering reusing stuff that has already been done

https://github.com/TouK/ThrowingFunction

try should have toOptional.

Alex A says it should throw an unchecked exception on get.

The repo doesn't have version tags, so it's impossible to reproduce a release from the source. Please consider pushing tags to your repo.

seems a little narcissistic to use my name in the packaging.
I bought combinator.ninja - there are some API breaking changes I'd like to make anyway after revisiting this with another year of scala under my belt. I think repackaging would reflect the community interest more.

We've found the lib very useful, thanks for it!
Unfortunately, there is one thing which prevents it to be used with org.springframework.web.bind.annotation.ControllerAdvice exception handling contrroller from spring-mvc
Every time the lib catchers exception it wraps the exception with RuntimeException.

Would it be better to wrap only checked exceptions and propagate unckecked as they are?

The project URL in the generated pom links to http://jasongoodwin.com/better-java-monads. The missing dash sends people to another site, which led to some confusion. 😃

I have Try inside CompletableFuture, and then 2 of these CompletableFuture are then linked with thenCombine and fed into another function All the existing exception handling logic works fine, but when I change thenCombine to thenCombineAsync all the exception handling logic seems to be ignored and I keep getting NullPointerException (even if the originally handled exception was something else).

I'm working with this in play - it should catch throwable.
It's more obvious with checked exceptions why this is a problem...

It's useful to handle the exception as input - these are needed combinators.