Develop Reference

Rewriting an if statement which throws an exception in a cleaner way

Let's suppose we have an if statement like this:
public A save(A a) {
if (isValid.test(a)) {
return aRepository.save(a);
}
throw new ANotValidException("A is not valid");
}
isValid is a Predicate and it may look like:
private Predicate<A> isValid = (a) -> (a != null);
What do you think? Can I make it cleaner somehow?
I mean, for example using an Optional to reduce it in 1 line with an .orElseThrow();

A more precise version using Optional and throwing a custom Exception shall be :
public A save(A a) throws ANotValidException { // throws the custom exception
return Optional.ofNullable(a) // since your predicate is to check for not null
.map(aRepository::save)
.orElseThrow(() -> new ANotValidException(a + "A is not valid"));
}

An Optional can make the code more readable, particularly around the use of your predicate object:
public A save(A a) {
return Optional.ofNullable(a)
.filter(isValid)
.map(aRepository::save)
.orElseThrow(() -> new ANotValidException("A is not valid"));
}
You can also get rid of the predicate altogether as it's simple enough to use Objects::nonNull (unless your real predicate's test is more complex). And in that case, keeping your current condition checks would probably make more sense (in my opinion).

One could argue that it would be more natural to read it in the opposite order, that is first handle the validation and the result of it and then move on to saving the object.
public A save(A a) {
if (!isValid.test(a)) {
throw new ANotValidException("A is not valid");
}
return aRepository.save(a);
}

rxjava2 - if else on Maybe

I am looking for what is the recommended practice in rxjava2 to handle a case where one flowable leads to conditional behaviors.
More concretely, I have a Maybe<String> for which I want to Update the String on the database if the String exists or, if it doesn't exists I want to create a new String and save it on the database.
I thought of the below but obviously it is not what I am looking for:
Maybe<String> source = Maybe.just(new String("foo")); //oversimplified source
source.switchIfEmpty(Maybe.just(new String("bar"))).subscribe(result ->
System.out.println("save to database "+result));
source.subscribe(result -> System.out.println("update result "+result));
The above obviously produces
save to database foo
update result foo
I tried also the below which gives the expected result but still feel it's... weird.
Maybe<String> source = Maybe.just(new String("foo")); //oversimplified source
source.switchIfEmpty(Maybe.just(new String("bar")).doOnSuccess(result ->
System.out.println("save to database "+result))).subscribe();
source.doOnSuccess(result -> System.out.println("update result "+result)).subscribe();
How can I have an action for when the result exists and when it doesn't exists? How is that use case supposed to be handled in rxjava2?
Update 01
I tried the below and it looks cleaner than what I came up with above. Note sure it is recommended rxjava2 practice however...
Maybe.just(new String("foo"))
.map(value -> Optional.of(value))
.defaultIfEmpty(Optional.empty())
.subscribe(result -> {
if(result.isPresent()) {
System.out.println("update result "+result);
}
else {
System.out.println("save to database "+"bar");
}
});

You have the isEmpty() operator that will return you Boolean if the Maybe source is empty or not, and then you can flatMap it and write a if else statement depending on that Boolean

This is a common pattern in our code as well, though in our case the choices are themselves async. You can't get quite the right semantic by simply composing flatMapX and switchIfEmpty (in either order), so I am curious why this isn't part of the API.
Here's what we're doing for now (this example for when the 2 options are both Completables, we have similar things for the other types as well):
public static <T> Completable flatMapCompletable(Maybe<T> target,
#ClosureParams(FirstParam.FirstGenericType.class)
Closure<? extends CompletableSource> completableSupplier,
Supplier<CompletableSource> emptySupplier) {
Maybe<T> result = target.cache();
return result.isEmpty().flatMapCompletable(empty -> {
if (empty) {
return emptySupplier.get();
} else {
return result.flatMapCompletable(completableSupplier::call);
}
});
}
We're using Groovy, so we package these up as extension methods. I'm not thrilled with the need to use cache() so I'm wondering if there is a better alternative. From looking at the code, an operator which basically combines flatMapX and switch looks like it wouldn't be too hard (but I feel like I'm missing something).

Try something like this. checkDB can return a Maybe or Single or whatever which emits either an optional or a wrapper Object.
checkDB(String)
.flatMap(s -> {
if (s.isPresent()) {
return updateDB(s.get());
} else {
return insertDB("new String");
}
})

There is an solution using the flatMap call with 3 params
fun addOrUpdate(message: LocalMessage): Single<LocalMessage> {
return getById(message.id) // returns Maybe
.flatMap(
Function {
update(message) // onSuccess update call returns Single
},
Function {
Single.error(it) // onError
},
Callable {
add(message) // onComplete add call returns Single
}
)
}
}
Or shorter version
fun addOrUpdate(message: LocalMessage): Single<LocalMessage> {
return getById(message.id) // returns Maybe
.flatMap(
{
update(message) // onSuccess update call returns Single
},
{
Single.error(it) // onError
},
{
add(message) // onComplete add call returns Single
}
)
}
}

Conditional operations in RxJava code

I'm new to RxJava and often find myself resorting to solutions like the ones below for conditional operations. Here I want to chain two calls in sequence, and then return an int depending on what the outcome of the call chain is. Are there any "rxified" way to improve this code? (using blockingSingle here since I'm passing the resulting int to a legacy application to which I cannot push values as of yet)
return restApiAdapter.closePosition(request)
.flatMap(dealReference -> restApiAdapter.getDealConfirmationObservable(dealReference.getValue())
.map(dealConfirmationResponse -> {
if (dealConfirmationResponse.getDealStatus() == DealStatus.ACCEPTED) {
return SUCCESS.getValue();
} else {
return FAIL.getValue();
}
})
)
.onErrorReturn(e -> ZorroReturnValues.BROKER_SELL_FAIL.getValue())
.blockingSingle();

After moving the logic to check for ACCEPTED/REJECTED orders as suggested by #andrei-macarie, the code now looks more like this
return restApiAdapter.closePosition(request)
.flatMap(dealReference -> restApiAdapter.getDealConfirmationObservable(dealReference.getValue())
.map(dealConfirmationResponse -> SUCCESS.getValue()
)
.onErrorReturn(e -> FAIL.getValue())
.blockingSingle();

if statements alternative with Java 8

Have a function like this:
public void toDo(Req req){
if(req.getSection().equals("A")) {
return execA(req);
}
if(req.getSection().equals("B")) {
return execB(req);
}
if(req.getSection().equals("N")) {
return execN(req);
}
}
How can I simplify it? The general idea, how to exclude if statements for the identification type of function - Strings - A, B, N. Any solutions with Java 8 like pattern matching with Scala?

Can't you use just a simple switch?
switch (req.getSection()){
case "A" : execA(req); break;
case "B" : execB(req); break;
case "N" : execN(req); break;
default: break;
}

Besides the switch solution, which works for strings and int values, you can use a Map:
Map<String,Consumer<Req>> handlers;
{
handlers.put("A", req -> execA(req));
handlers.put("B", req -> execB(req));
handlers.put("N", req -> execN(req));
}
Consumer<Req> defaultBehavior=req-> {
throw new IllegalArgumentException(req.getSection());
};
public void toDo(Req req) {
handlers.getOrDefault(req.getSection(), defaultBehavior).accept(req);
}
Besides supporting other key types, it allows to assemble the map at runtime, e.g. using handlers provided by different, perhaps dynamically loaded, modules, etc.

Using reflection and the array of methods you have on your class, you could apply a filter (if-replacement), mapping (to return value) and optionally defining a default value (orElse).
This approach might be good, if either the number of cases gets huge or dynamic. But for your particular case, I think it's overkill. Better stick to the switch-case solution.
public Optional<Object> toDo(Req req) {
return Stream.of(this.getClass().getMethods())
.filter(m -> m.getName().equals("exec" + req.getSection()))
.map(this::invokeUnchecked).findFirst();
}
private Object invokeUnchecked(final Method m) {
try {
return m.invoke(this);
} catch (IllegalAccessException| InvocationTargetException e) {
throw new RuntimeException(e);
}
}
In case you don't want to use an optional, you have to declare a default with .findFirst().orElse(() -> ...)

If not null - java 8 style

Java 8 presents Optional class.
Before (Java 7):
Order order = orderBean.getOrder(id);
if (order != null) {
order.setStatus(true);
pm.persist(order);
} else {
logger.warning("Order is null");
}
So on Java 8 style:
Optional<Order> optional = Optional.ofNullable(orderBean.getOrder(id));
optional.ifPresent( s -> {
s.setStatus(true);
pm.persist(s);
//Can we return from method in this place (not from lambda) ???
});
//So if return take place above, we can avoid if (!optional.isPresent) check
if (!optional.isPresent) {
logger.warning("Order is null");
}
Is it correct to use Optional in this case? Can anyone propose a more convenient way in Java 8 style?

Unfortunately, the ifPresentOrElse method you're looking for will be added only in JDK-9. Currently you can write your own static method in your project:
public static <T> void ifPresentOrElse(Optional<T> optional,
Consumer<? super T> action, Runnable emptyAction) {
if (optional.isPresent()) {
action.accept(optional.get());
} else {
emptyAction.run();
}
}
And use like this:
Optional<Order> optional = Optional.ofNullable(orderBean.getOrder(id));
ifPresentOrElse(optional, s -> {
s.setStatus(true);
pm.persist(s);
}, () -> logger.warning("Order is null"));
In Java-9 it would be easier:
optional.ifPresentOrElse(s -> {
s.setStatus(true);
pm.persist(s);
}, () -> logger.warning("Order is null"));

//Can we return from method in this plase (not from lambda) ???
Lambdas do not implement "non-local return" semantics, therefore the answer is no.
Generally, since you need side-effectful action in both the case where the value is present and not, a branching point in the code is essential—whether you wrap it in some fancy API or not. Also, FP generally helps improve referentially transparent transformations (i.e., code built around pure functions) and not side effects, so you won't find much benefit by going through the Optional API.