It's more general than this, but in this example it's a chain of three functions, f, g, h, each of which can fail in the same way. The precise failure behavior is encoded in the types themselves, so there is no need to check for it explicitly in the code. If `f` doesn't work, then `g` won't run, and the failure will be handled as expected by the functions' return types. Maybe they'll return an error message or maybe they'll be a "null" sort of value; the types will tell you, but the chaining syntax itself will always be the same.

It's far more common to see this chaining done with `do` blocks but I wanted to keep it all on one line.

This lends itself to a clean and optimistic sort of programming. You just write what you want to happen, chained within the broader context of some exception that might occur. So I agree with the parent that static typing makes things faster and easier, but I would argue that most unhappy paths don't require unique attention, and that it's language smell to make you care about them.

Thanks! It's hard to imagine how this would work in a complex example that has multiple error paths, but I understand what you mean in the case of same types/one error case. Railway Oriented Programming and all that.