Isn't the point of options to statically rule out the possibility of NPE's?

    def f1:Option[Int] = Some(1)
    def f2(a: Int):Option[Int] = Some(a + 1)

    val r = for {
        a <- f1
        b <- f2(a)
        c = a * b
    } yield c
    r.getOrElse("generic error")

Individual error messages with scalaz's Validations

    def f1:Option[Int] = Some(1)
    def f2(a: Int):Option[Int] = Some(a + 1)

    val r: Validation[String, Int] = for {
        a <- f1.toSuccess(e = "f1 failed")
        b <- f2(a).toSuccess(e = "f2 failed")
        c = a * b
    } yield c
    r.fold(e => s"error: $e", r => s"result: $r")

The problem is that on the JVM, you are given a debugger based on control flow, not data flow. Once you go into heavy option code, debugging that code becomes a PITA because your tools are simply wrong. So ya, you can come up with what basically amounts to a printf for data flow code, but you are stuck doing everything on your own at that point.

The problem really stands that no one knows how to build decent data-flow debuggers. Haskell programmers prefer static safety over debugging just as much as because their debuggers suck as the type system is so powerful. In Scala, you have the option to write crash-early strict code: do it, you will make your life so much easier as a result.

Is it realistic to split long chains of Option into subfunctions returning Option? If long chains of Options are hard to effectively reason about, breaking them up could ameliorate the problem.

I suppose that conceptually, I consider returning None inside a chain of flatmapped options as the equivalent of terminating early. It's not hard to pass along an object describing the error instead of None, which gets you the equivalent of a thrown exception.

Also: can you point me towards any examples of this antipattern? I 'd like to see it in action, if only so I can avoid it in my own code.

I found the best way to debug a complex piece of scala code was to get rid of as much laziness and deferral as possible. Creating a huge lazy sequence that propagated through multiple call-layers was absolutely evil. Also, options, although strict, are troublesome across more than a couple of lines of code given the way they crash. In general, only use option if failure is expected, otherwise null is your friend!

For simple programs that do not need to be debugged, laziness is great, you can write some very concise code. Once you are debugging however, you want to expose as much control flow as possible to break and step through. I say this from writing 10s of thousands of Scala code in a fairly complicated context (Scala compiler + Eclipse) with non-trivial control flow (mostly event driven).