Java Without If

352 points by tretiy3 9 years ago | 208 comments

mabbo 9 years ago |

Optionals are a huge step forward for Java, even if they aren't perfect. They let you write interfaces that say "I might not have an answer and if you don't deal with it that's your problem". That's important.

That they also allow mapping, filtering, etc, isn't about 'removing ifs' or 'hiding ifs' so much as they are about writing more readable code, imho.

  Optional<Foo> myValue = gateway.callThatApi(...)
  return myValue.filter(Utils::isNotTooShabby)
                .map(this::mapToCoolerType)
                .map(getDecorator())
                .orElseThrow(new TotallyBlewItException())

Is this perfect and beautiful? Nah. But it's better than the 20 lines of Java 7 code I'd need to do the same thing. I'm able to write simple predicates and mapper functions as class variables, dynamically if I want, and call them in order as I like. It's short, it's descriptive rather than prescriptive. It isolates what I want from how I do it.

Debugging is annoying, yes, but I think there's hope that a good pattern for it will be figured out by the community.

gravypod 9 years ago | |

Why is Optional<> better then throwing an exception or returning a null?

The way I see it it's like this:

    Optional<Integer> num = getSomeRiskyNumber();
    if (!num.isPresent())
        return ... code to bubble up a blank optional

    Integer num = getSomeRiskyNumber();
    if (num == null) 
        ... throw exception or return null

I get that the author has adopted a more functional programming methodology for dealing with their data but for some tasks this isn't acceptable. To just return 1 value you've allocated at least one object (Optional) and make at least 2 function calls on it (isPresent() and get()).

You get `if (value == null)` for free. Throwing exceptions is very heavy and I'd place Optional<> above that but there isn't any way to signify the error that you acctually got. You'd need to make an Optional<Maybe<T>> where Maybe<T> supports error/exceptions. Maybe Maybe<T> holds data and you can extend it with BadMaybe<T> who extends exception or something so you can put that in instead of your value to signal your exception.

I don't see the benifit. Maybe I'm just crazy but `if (v == null)` has all the features Optional has for less of an overhead and less cognitive load. (If you're afraid of NPEs then just document all the return states of your methods and use @nullable to show when you need to check. IIRC IntellJ catches that kind of mistake).

village-idiot 9 years ago | | |

The point of a static type system is to have the language help you out as much as possible to write type-error free code. It can't guarantee that you haven't messed up, but it's supposed to help.

Null ruins that. It's a known source of runtime exceptions, and it is not a compilation error to return null or forget the null-check. It is a compilation error to pretend that an Optional<T> is just a T. The Java compiler is not smart enough to prevent you from doing something silly like calling get() on Optional<T> without checking isPresent() first, but at least it gives you something.

Also Optional has some really nice creature comforts. It gives you the ability to map to compose an Optional<T> with functions that couldn't care less about the Optionality, and it lets you use flatMap to chain successive calls that might fail together, avoiding an arbitrary number of null checks (that you might forget!) in your code.

Frankly arguing against Optional<T> is like arguing against map on lists/streams and saying that for is good enough for you. You can do it, but I think you'd be nuts to work against yourself like that.

mabbo 9 years ago | | |

Simple answer: never return null.

If something is wrong, throw an exception. If it's the kind of error that must be handled, throw a checked exception. If there's no value to return, return Optional.empty.

The code receiving that Optional<Foo> is now free to do what the author is suggesting: map, filter, all without worrying if the value is actually there or not. The code is cleaner, easier to read, etc.

But no one should ever have to check for null anymore.

chii 9 years ago | | |

you shouldn't really be running `optional.isPresent()`, but rather, use a map operation, or a flatMap operation, all the way until you need to interface an outside api (in which case, you use a `getOrElse(defaultValue)`).

You're right about code that branches based on `isPresent()` is semantically the same as null checks - and if you only did that and didn't use any functional paradigm like mapping on the types, you don't really get any real benefit!

ahoka 9 years ago | | |

Optional types shine the best when you can chain them:

BufferedImage avatar = users.getUser(userName) .flatMap(User::getAvatarUri) .flatMap(ImgIO::read) .orElse(anonymousAvatar);

I made this up, but I hope you see the point. Optional is just a fancy null pointer if you don't use it in a functional way. :-)

andrewjf 9 years ago | | |

I think the most benefit of wrapping the result in an optional is so you can use compiler to enforce exhaustive pattern matching[1].

   Optional<Integer> num = getSomeRiskyNumber();
   match num {
     Some(x) => ... ;
     None => return error or whatever;
   }

The compiler will verify you at least pretended to look at the None result instead of just ignoring it (but you could still swallow the none).

1: does java even have this?

staticassertion 9 years ago | | |

Optional forces the null check (at the cost of a pointer dereference :( but that's Java for you). That's the difference.

It also provides some nice combinator syntax for handling that null beyond .isPresent, but if you were to just get .isPresent it would be a win.

Documentation is optional (hah) and therefor shouldn't be relied on.

Optional as a return type means there's no need to check for documentation, there's no need for @Nullable, and you get some pretty syntax to boot.

wrsh07 9 years ago | | |

A few things that need responding to. First, optional is the same as a maybe. They're different names for the same thing.

If you want to return a status instead of nothing, you use an Either type (as mentioned in the post). In an Either, you populate left or right, but not both. You can let left be your status and right be your template type. You could codify this as StatusOr<T>.

In a StatusOr land, you return if there's an error; otherwise you continue the computation. This gives a few advantages, but one is that you control the flow of control. (This is also done decently with exceptions in Java, iirc)

However, all of these - maybes, either - they make your functions composable.

There's a good talk... Railroad oriented programming... that dives into this.

mark242 9 years ago | | |

In Scala, you're encouraged to write more bulletproof code by avoiding exceptions at all time, simply because it's easier to realize that (in your case) getSomeRiskyNumber returns an option instead of an integer.

  getSomeRiskyNumber map {
    case Some(i) => Map("risk" -> i)
    case None => Map("error" -> "Error retrieving number.")
  } map { response =>
    Json.toJson(response) 
  }

Reading this code you know you're always going to generate a json response to the user, and depending upon what getSomeRiskyNumber() returns, the json response will either look like { "risk": 23 } or { "error": "Error retrieving number." }. No exceptions needed.

coldtea 9 years ago | | |

>Why is Optional<> better then throwing an exception or returning a null?

https://www.infoq.com/presentations/Null-References-The-Bill...

dragandj 9 years ago | | |

> To just return 1 value you've allocated at least one object (Optional)

May be nitpicking, but in your other example, you've allocated at least one object (Integer) to just return 1 value, which means that supertight performance is not important in getSomeReskyNumber

Joeri 9 years ago | | |

First of all, the use of isPresent is a red flag that optionals aren't used right.

You'd typically use a sequence of map, flatMap and orElse calls. For example, this is some controller code I'm currently shipping:

    return Drawing.getForLocation(id)
        .map(d -> ok(Json.toJson(d)))
        .orElse(notFound("No drawing for location " + id));

That construct is more readable to me than an if(drawing != null) check. The cognitive load issue is a bit of a red herring. I'm used to optionals now and they're no more of a cognitive load than an if construct. But that's eye of the beholder stuff, so let's park the cognitive load issue for now.

Getting down to the meat of your argument, why is optional better than an if not null check or an exception?

I think anyone can see why it's better than throwing an exception. Optional makes it obvious to the caller that (a) there can be no response, and (b) what happens exactly when there's no response. With exceptions, either they're unchecked, in which case you don't know what exception to catch without peeking, and it's really easy to forget to add a try/catch handler at all; or it's checked, but even in that case the handling code is uglier than an equivalent optional construct.

The more interesting question is why it is better than deliberately returning null. Again, it's about signaling. A library author can signal to the caller that they should expect not to get a value sometimes. Yes, it's possible to return null from a method that returns an optional, and this will cause an NPE, but in that case the error is the library's, not the callers. In making API's, you want to encourage correct use, and optionals help do that.

Optionals in java suffer from the same problem as most API's in java do though. They're uglier than they need to be, and some common use patterns are awkward. For example, in my spark code in scala I'll use constructs like this one to convert a stream between types where the conversion might fail for some elements (and I don't care about the ones where it does):

    val someIntermediate = someStream.flatMap(convertMaybe)

That works because Option can be handed to flatMap directly.

But in Java streams, you can't do that, and you end up with constructs like this:

    someStream.map(convertMaybe).flatMap(o -> o.isPresent() ? Stream.of(o.get()) : Stream.empty())

Which is insane. In Java 9 they're kind of sort of fixing this and it's going to be

    someStream.map(convertMaybe).flatMap(Optional::stream)

Which is still ugly though.

Any way, I think optional has its uses in Java. It's definitely something that helps when building out robust API's. But where optionals would be most valuable, the combination with streams and futures, is where they're painful to work with. That's par for the course in Java though. Oracle's not actually all that good at designing API's. Usually the first attempt at something turns out so broken it has to be replaced wholesale later (like java.util.Date), or it's so ugly it feels bad to use it (CompletionStage? seriously?). But, to each their own, I'm sure my attempt at it would be even worse, and despite the warts I still like Java 8 overall.

Retric 9 years ago | |

What's wrong with generics here?

  ListCondi<ObjType> myValue = gateway.callThatApi(...)

  foreach(tmp as Condi in myVlue)
  { 
    if  (tmp.worked) { foo(tmp.Generic);}
    else {bar(tmp.Generic);}
  }

PS: Sorry, have not touched java in like 10 years, but I assume you can have that foreach as a map.

mabbo 9 years ago | | |

In my case above, there's just one object, maybe (or maybe there isn't?).

In the case you're presenting, one might consider:

  Stream<Foo> myVals = gateway.callThatApi(...)
  return myVals.forEach(val -> getFooOrBar(val).apply(val))

Not quite as nice as Scala would let me do it, but closer, simpler.

Streams also let you add filters to the "list" of values, reduce them to a single value with a reducer, or use a nice set of "collectors" that reduce to Java generic collection types. (Collectors.groupBy is so handy).

Streams are also lazy, which I think is more good than bad.

The thing I tell everyone to do right now, today, is to open their Java code and search for "return null", then replace it with "return Optional.empty()". It'll break your code in lots of places, but things will be better when you fix all those things. Often you'll find lots of places that didn't handle the null possiblity at all!

wellpast 9 years ago |

This is just lipstick.

The real problem is branching - when reading code I have to think through two conditional cases.

In this particular example (where you have to validate a client request), I don't see a way out of branching. However I don't think this post has produced the ideal:

    JsonParser.parse(request.getBody())
       .flatMap(Validator::validate)
       .map(ServiceObject::businessLogic)
       .flatMap(JsonGenerator::generate)
       .match(l -> HttpResponse.internalServerError(l.getMessage()),
              r -> HttpResponse.ok(l));

The problem with this is that I have to think through branching all the way through the data flow. However the only function that should branch is validate, to prepare the request to meet the preconditions of the rest of the data flow, all of which should be non-branching.

In other words, I should be able to read this part of the data flow without thinking of branching:

   (generate-json (business-logic req))

So this I believe is objectively better:

   (if (valid? req)
      (generate-json (business-logic req))
      (generate-json (errors req)))

Yes, I've used an if. (If we don't like ifs we can easily get rid of it, of course - but again our problem is branching not the if.)

Why is this objectively better? Because we now have to think about branching wrt to the validation function ONLY. We've minimized where branching matters, and that's solving the core issue.

cjensen 9 years ago |

I like functional program a lot, but that very first transform of a chain of if's into a horrifying mess makes a pretty good case for using if. In the if case, function2 and function3 were called identically, but in the functional case suddenly things are inconsistent.

Is this a satire?

chc 9 years ago | |

They're called identically in the if case, but they're not used identically. One of functions isn't guaranteed to return a value, so it requires an "if x != null". flatMap basically says "this might be null." Part of the point here is that it makes it explicit when something might return null and ensures it's handled properly.

Doradus 9 years ago | |

It doesn't take long to get used to that style. It took me maybe three weeks of playing with Java 8 streams in my spare time before I got quite comfortable with it.

kbuchanan 9 years ago |

I feel like the article took a surprising and unusual position - "We prefer Java to Clojure now" - but, then, instead of justifying that position, instead showed how Optional lets you write more functional Java.

It's been a long time since I've written any Java, so I wonder, how is this better than Clojure?

virmundi 9 years ago | |

Typing. I like Clojure. I've made a few simple libraries for it while learning. What I don't like is making web service contracts in it. The lack of typing makes the code hard to follow once you get past the first handler. Java keeps types around.

raspasov 9 years ago | | |

Checkout clojure.spec - you might find it very useful. The problem with types is that they are only a static/at rest description of your data. For example, it's a String or it's a Date.

But does that String contain @ character (checking for email)? Is this Date in the future or in the past (validating a credit card form)? Types say nothing about that. I'm not saying that types have zero utility, but in the vast majority of my use cases compile-time type checking doesn't go very far.

jankotek 9 years ago |

Optional types are clumsy when compared to modern alternatives:

- Optional does not protect from NPE, null is still allowed

- It adds extra layer of complexity

- some libraries use it, some do not. it is not enforced

- extra typing, Java does not even have type inference and `val` declaration

- `if` expression in java does not return a value, no pattern matching... again far more typing

- no support for chained call on several nullable fields

I use Kotlin for couple of years. It has nullability baked into type system and enforced by the compiler. And it works with existing java libraries.

It feels like going back 15 years to Java 1.4, when I use Optional in Java8 or Scala.

sid-kap 9 years ago | |

True. In practice, though, this isn't a problem. Most Scala code I've worked with just pretends `null` doesn't exist, which is a fair assumption if you're interfacing with well-behaved Scala libraries that never return null.

pkolaczk 9 years ago | |

Kotlin can't abstract over optional types. Scala Option is a monad which let's you do plenty of cool and useful stuff that Kotlin can only dream of. Kotlin solution is actually more complex, because it is baked into the language as a special case with special syntax.

edem 9 years ago | | |

Scala is still a baroque abomination which excels in nothing and the advantages are shadowed by its warts. Kotlin is just Turbo Java.

xg15 9 years ago | |

Also, the type seems to be designed oddly inconsistently in java (differences between Optional<Integer> and OptionalInt, obvious applications like tryGet() missed, etc) and I've read somewhere the designers themself discourage it for many use cases. I don't know why this is the case though.

throwawayish 9 years ago | |

We're using Kotlin extensively at work and a very happy with it. Spending a couple weeks on converting most of our codebases to mostly-Kotlin-little-Java has given a nice boost to developer morale from my PoV.

nilved 9 years ago | |

Nothing you just said is true. Optional doesn't add complexity, it makes complexity explicit. The rest is just Java implementing it poorly.

jankotek 9 years ago | | |

And because it is implemented poorly, it adds complexity. Even Scala, which had Option from start, has three ways to return value from Map (Option, nullable return value, and throw an exception if not found). Kotlin has only single way.

ajkjk 9 years ago |

Is there a non-traumatizing way to debug long chains of method calls? I had a lot of trouble with this when I last used Java, a year or so ago.

amelius 9 years ago |

Isn't this just pushing the "if" into the called functions? E.g.,

    x = something that might result in an exception
    x = f(x)

Now f has to check whether x contains an exception, and it should return that exception in that case, and otherwise it should just apply the function to the argument.

Sharlin 9 years ago | |

This is exactly what the flatMap (aka monadic bind) calls do. flatMap/bind is sometimes called "a programmable semicolon", allowing one to customize what happens when chaining operations.

trevor-e 9 years ago | | |

Can you explain the "a programmable semicolon" part? I've tried and tried and can't think of any way that makes sense to me. I use flatMap all the time but still don't understand the expression.

beached_whale 9 years ago |

As nice as it would be to have a method in java that cannot receive a null argument like Result method( Type NOT NULL name ), it isn't there.

I fail to see much difference between an Optional has/doesn't have a value and null. It's just paint and there is no insight into why there is no value. Something like an Expected type that has either a value or the Error/Exception is much more explicit and may let someone do something about it. At least then the user of the method can choose what an appropriate action is with knowledge. But optional and null are the same and give you no more information than a result or that there is no result.

village-idiot 9 years ago | |

Why is map and filter nice on a list? Because the individual functions passed in have no idea they're in the middle of a map or filter. Ditto with mapping or filtering on Optional or Either. It composes better.

EdSharkey 9 years ago |

Someone smarter than me can explain why and how, but I had also heard that streams in Java can perform better than equivalent imperative code as well as being null-safer.

This is because the standard library can forego memory allocation for temporary data structures implied in expressions throughout the stream statement. Also, the Java 8 VM can apply other aggressive optimizations to the lambda functions to inline them.

mike_hearn 9 years ago | |

Sadly, no. Code written in this style will typically run more slowly, or be equivalent at best. Streams can perform better if you make them parallel and have lots of data as then you can more easily spread out over multiple cores (which is the point of streams), but most cases aren't like that.

When you heavily use stream constructions, you're relying on the JVM to:

• Synthesise classes for the lambdas.

• Inline the map/filter/fold calls and then inline the lambdas too. The JVM doesn't make any guarantees about inlining and may unpredictably bail out. If inlining doesn't happen then profile pollution will kill off some of the other optimisations the JVM does.

• Escape analyse any temporary objects created like iterators and then scalar replace them.

• Try and do some loop fusion, but I'm not sure to what extent the JIT compilers can do that.

This is a long list of complex and often fragile optimisations. If any of them don't get applied then you end up with virtual method calls, objects being created, poor cache utilisation etc. Sure objects that die young are cheap but they aren't entirely free. It's still best to avoid them.

The reality is that writing traditional style code is going to be more efficient or at least more reliably efficient than functional style code for the forseeable future.

Note that the JVM has a much easier time of it when using Kotlin's support for lambdas and functional programming because the inlining is guaranteed to be done by the Kotlin compiler not the JVM, and that fixes a lot of issues with profile pollution and unpredictable performance drops.

dtech 9 years ago | |

Theoretically there's all kinds of optimizations possible, but I don't think Java/the JVM does a lot of them. The main advantage you'll get is lazyness.

iopq 9 years ago |

I did FizzBuzz in Rust without using ifs:

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/bf4968973d73...

slantedview 9 years ago |

There are a few of these functional style programming APIs for Java. My favorite so far: JavaSlang [1]. Would be interested to see how it compares to the Lambda library mentioned in the article.

[1]: http://www.javaslang.io/

markelliot 9 years ago |

Conceptually this seems to be a Java approach to Railway Oriented Programming (http://fsharpforfunandprofit.com/rop/), which is pretty sweet.

edem 9 years ago |

So what was the problem with Clojure? The article makes no connection between the demonstration of the benefits of Either and why they ditched Clojure. As a Clojure user I can only imagine that they did not have the competency (hiring problems for example). Why don't you just pick up Kotlin and forget about nulls altogether?

village-idiot 9 years ago | |

Try to up your reading comprehension before you question the competency of others.

edem 9 years ago | | |

Try to down with the sickness your brain has before commenting something utterly useless and calling names. I was talking about the lack of competent workforce.

SeriousM 9 years ago |

The fact that you don't write "if" doesn't mean your aren't using it. Dann clickbait.

fulafel 9 years ago |

Inventing your own dialect of a language when none of the libraries support it sounds like you are going to be writing a lot of wrappers or reimplementations of things?

I would have really liked to hear what the argument for switching to Java is - over staying on Clojure or switching to a language other than Java.

draw_down 9 years ago |

I feel like, if you mean "if" say "if". As opposed to doing a little dance that has the effect of "if true do this, otherwise do that".

nv-vn 9 years ago | |

One could argue that if you mean "map" use "map", not a little dance with a for loop. I'm inclined to say that the same argument could he applied to "if", but without seeing what their particular code looks like I don't know for sure.

pekk 9 years ago | | |

And if you are mapping not to a value but to the execution of a statement, should that be map instead of for?

draw_down 9 years ago | | |

Well, I agree with that. If you're mapping use map instead of a for loop.

bananaboy 9 years ago | |

Yeah to me the example in the post looks very obtuse and unreadable compared to the standard "if" version. I prefer clarity in my code especially when I have to come back to it in six months to debug it.

a3n 9 years ago |

> Optional gives us the ability to say “if a value exists, apply this function to it” repeatedly. It also gives us the ability to chain successive calls ...

It sounds like a ternary operator to me.

DrJokepu 9 years ago | |

It's not really a ternary operator though, because the value that is tested for existence is only evaluated once, e.g. instead of

    a != null ? fn(a) : null

it's more like

    (a, fn) => a != null ? fn(a) : null

nurettin 9 years ago |

Java is already laden with a myriad of utilities such as streams and iterators which allow you to bypass some of the null checks when dealing with IO or collections.

If you want to chain calls, you could do that easily by passing "possibly null" returned values to methods with parameters that are marked @NotNull and handling null checks as exceptions down the line instead of inventing the optional type.

etaty 9 years ago |

Really Hacker news?!

We should use exception all the time. We should adopt exceptional programming.

null is the type to return, just in case we haven't thrown an exception yet.

Everyone know the exception API, how to throw them, how to catch them, we have to use it all the time. It's great.

We definitely don't need a strong type system, we need an exceptional programming language, everything is an exception.

alexatkeplar 9 years ago |

It's quite old now, but this is still one of the best tutorials on dealing with failure in FP (here, Scalaz):

https://gist.github.com/oxbowlakes/970717

dudul 9 years ago |

It's kind of cute to see Java practitioners discover what has been around in many functional languages for literally decades :)

But, hey, if it helps make Java code cleaner and safer (and Optional and Either definitely help a lot with that), I'm all for it.

jfoutz 9 years ago | |

The oldest version I can think of was Konrad Zeus's architecture for real computers. Sigma with index variables forcing an expression to zero capture the same concept. Pretty sure that is an old old idea.

Who did it first can be interesting, but it's rarely much use.

beached_whale 9 years ago |

This is still possible

java.util.Optional<int> opt = some_null_returning_function( );

hedora 9 years ago | |

Hey, don't knock it! Maybe I want a null reference to an Optional<int> to mean something different than a non-null reference to an optional that contains a null reference to a boxed Integer.

Database theory tells us that having multiple null values is useful ("eh, I don't know" vs "your question has no meaning").

Seriously though, it would be great if they just added a "non null reference" type to the language. C++ has this, and it is useful (even though the compiler doesn't enforce the non-null bit).

The thing that always irked me about Optional<T> is that they are synonymous with bare Java references (which also can be null, at least according to the language spec / compiler). It is like a Java version of

#define THIS_PROGRAM_IS_WRITTEN_IN_C *

to my eyes.

To each their own.

ebola1717 9 years ago | | |

Eh, in that case you should roll your own container type appropriate to the business logic, e.g. DBWriteResult<T> (or return Optional<Optional<int>>, but probably not that)

beached_whale 9 years ago | | |

clang will(at least v4 will) tell you you did a silly thing if it can reason that your a statically binding a reference to nullptr. int & i = (int)0;

Not sure how far it can go down the rabbit hole though. This is really where value types/regular types are really nice.

I think it would have been better for Java to allow the flatmap like stuff for any reference instead of creating an optional. But I am not a fan of either for when there is no value due to error conditions. There are optional values and there are errors that prevent the fulfillment of the contract. So either throw so something can be done or return a class that can either be an error or the value. But returning null does not allow the caller to act on it.

You are so right though about non-null references. I would go further and say nullable should not have been the default but an added keyword. That is the trait of a c++ reference I like. Just use it and don't check for null. With that Optional can have some differentiation and is meaningful for situations where an error hasn't occurred.

jayajay 9 years ago |

> objects don’t magically construct themselves from unstructured data

Very out of context, and very off topic, but this is a profoundly deep statement... its veracity is questionable and unknown.

oconnor663 9 years ago |

The Either type there is very similar to Rust's Result type.

village-idiot 9 years ago | |

Neither are new concepts, both are probably lifted from Haskell which probably got it somewhere else prior.

Inufu 9 years ago |

tl;dr: Don't use Either<L, R> for error handling, it's too general. Use StatusOr<T>.

More details: http://www.furidamu.org/blog/2017/01/28/error-handling-with-...

hakcermani 9 years ago |

In the parse example if the parse fails would we end up with 4 more function calls ? (rather than one if check and a bail out)

village-idiot 9 years ago | |

Any function like map or flatMap that only affects one side of the either is a no-op if the current value is the wrong side. It's a bit like calling map on an Optional::empty, a no-op.

ndesaulniers 9 years ago |

part two will be titled "Shaders and SIMD without If: scattering and gathering"

rco8786 9 years ago |

So, Scala.

Sharlin 9 years ago | |

Without the huge complexity of Scala and faster compile times. Java 8 is actually a surprisingly pleasant language to write.

arximboldi 9 years ago |

  The potential for JSON parsing to fail is encoded in its
  type, not in the potential for a variable to null, or
  false, or for an exception to have been thrown. You’re 
  leaning on the compiler to tell you if you’ve handled the 
  failure cases properly, as the code won’t compile 
  otherwise. Now instead of testing for runtime exceptions 
  you only test to make sure that your business logic is 
  correct.

Last time I did Java (it like 7 years ago) the compiler did enforce exceptions types as part of the signature. Has this changed in between? Otherwise this does not seem like a valid argument to me.

The OP does discuss checked expcetions a little bit:

  Checked exceptions guarantee that someone will deal with 
  the issue, but they are extremely annoying, and might 
  result in disparate and different exception handlers all 
  over the place.

They don't explain why exceptions are annoying (because the compiler checks them, just like optional?) and technically there should be exactly the same number of try-catch handlers as match calls in equivalent Optional<> code... It seems to me that his arguments are mostly based on aesthetics. Something the author half-acknowledges by starting their discussion with "Well, first off I think it’s beautiful."

There are some actual problems with exceptions though:

1. It may be hard to tell from looking at the code which particular calls inside a function produce which particular kinds of exceptions.

2. This is particularly problematic with stateful code, as to ensure exception-save stateful transactions.

3. They tend to be more expensive for the exceptional codepath -- on the other hand, they are faster than Optional for the non-exceptional path!

In my experience points 2 and 3 are the most important. Since in Java many things may throw, one has two think about exception safety anyways most of the time. This is also a good argument maybe, to just avoid statefulnes instead.

Point 3 is very important. Maybe exceptions should be relegated to truly exceptional situations, and not be used as a replacement for an if. Optional<>/Either<> is excellent in this sitiation. Still in some languages do use exceptions for this and familiarity might be something to consider there (I'm thinking of idiomatic Python signals iteration end or key presence in maps, but Python also has very different performance characteristics as Java and does not have static types for the most part anyways...).

As much as I actually love FP, and I am also trying to bring more FP to other languages (C++), I don't believe in fighting the language for the sake of it. Having a nuanced conversation about the "why" and a the "when" is important. Specially when bringing these techniques to communities that are not used to them and, at the end of the day, already have methods that "Just Work TM". Otherwise, you end up having reactions like this: https://news.ycombinator.com/item?id=13505620

general_ai 9 years ago |

2 years from now: "we got rid of all the functional bullshit and we're now using ifs and for loops all over the place; reminds us of our fixie bicycles and other aspects of our hipster lifestyle".

Over the past two decades I've internalized the value of writing code that's very easy to understand. Otherwise 6 months later I can't figure things out myself. This Java style reminds me very much of Scala which seemed like a decent language until I saw how people actually use it in practice. Noped right out of that in a hurry.

Parse and validate the request If that fails then return 400, "invalid request: " + err Run business logic to get a result If that fails then return 500, "logic failed: " + err return 200, result as JSON

module Raindrops (convert) where import Control.Monad (liftM2) import Data.Foldable(fold) import Data.Maybe (fromMaybe) convert = build rules build = liftM2 fromMaybe show . fold rules = uncurry rule <$> [(3, "Pling"), (5, "Plang"), (7, "Plong")] where rule i s j = if j `mod` i == 0 then Just s else Nothing

IntPredicate even = i -> i % 2 == 0; IntUnaryOperator add2 = i -> i + 2; UnaryOperator<IntStream> process = s -> s.filter(even).map(add2); for (int i in process.apply(numbers)) { System.out.println(String.valueOf(i)); }

public List<Integer> add2(File file) { List<Integers> nums = file.getNumbers(); if(nums != null) { List<Integer> resultList = List<>(); for ( i : nums) { resultList.append(i + 2); } return resultList; } else { return null; } }

public Optional<List<Integer>> add2(File file) { Optional<List<Integers>> numsOpt = file.getNumbers(); return numsOpt.map((nums) => nums.map((i) => i + 2); ); }

public List<Integer> add2(File file) { List<Integer> resultList = new ArrayList<>(); for (int i : ListUtils.emptyIfNull(file.getNumbers())) { resultList.append(i + 2); } return resultList; }

public List<Integer> add2(File file) { List<Integers> nums = file.getNumbers(); // Show where the data comes from if(nums == null) { // Show the invariant provided for the rest of the code return Collections.<Integer>emptyList(); // Show the default return value if there has been an error } List<Integer> resultList = List<>(); // Apply your logic for ( i : nums) { resultList.append(i + 2); } return resultList; // Return your list }

public List<Integer> add2(File file) { // Show data source List<Integers> nums = file.getNumbers(); // Show case where data is supplimented if(nums == null) nums = Collections.<Integer>emptyList(); // Show supplimnetal // Show transformation List<Integer> resultList = List<>(); for ( i : nums) { resultList.append(i + 2); } return resultList; }