Null handling: broadly speaking, not a thing in Scala. Idiomatic Scala shuns nulls pretty religiously: indeed, the whole point of Option is that it replaces the concept of null with something better-typed. While nulls can't be entirely ignored (they show up when you interoperate with Java/JavaScript, and occasionally at other times), the policy is to scrub them out on contact, so the rest of the code doesn't need to deal with them. So yes: that is very intentionally ignored, as a matter of proper design.
Error handling: the Option example *can't* have exceptions -- there's just nowhere in that code for them to crop up. Ditto for the List example. In the case of Future, they get bundled *into* the Future. I didn't take the time to explore that in detail (since it's off-topic), but basically you attach a "recover" handler to your Future, which means "if the following Exceptions arise, do the following". It's basically the same as try/catch (in Scala and many other languages), but asynchronous.
You have some capital "S" that make me want to ask whether that's a typo
I suspect the ones you're looking at are just a font illusion: they're lower-case, but lower-case Helvetica at the end of an otherwise Courier word looks weird.
You use "..." and I can't tell if that's a legal thing in your language or something you're using to avoid having to write out code that isn't relevant to the point you want to make.
The latter. (Although ??? *is* actually literal Scala -- it's a function that throws a NotImplementedException, and is delightfully useful.)
You use "functor"
Like I said -- it's math jargon. (Not my fault.) It *is* semantically related to "function", but the relationship is fairly complex, having to do with the way types relate to each other.
no subject
Null handling: broadly speaking, not a thing in Scala. Idiomatic Scala shuns nulls pretty religiously: indeed, the whole point of Option is that it replaces the concept of null with something better-typed. While nulls can't be entirely ignored (they show up when you interoperate with Java/JavaScript, and occasionally at other times), the policy is to scrub them out on contact, so the rest of the code doesn't need to deal with them. So yes: that is very intentionally ignored, as a matter of proper design.
Error handling: the Option example *can't* have exceptions -- there's just nowhere in that code for them to crop up. Ditto for the List example. In the case of Future, they get bundled *into* the Future. I didn't take the time to explore that in detail (since it's off-topic), but basically you attach a "recover" handler to your Future, which means "if the following Exceptions arise, do the following". It's basically the same as try/catch (in Scala and many other languages), but asynchronous.
I suspect the ones you're looking at are just a font illusion: they're lower-case, but lower-case Helvetica at the end of an otherwise Courier word looks weird.
The latter. (Although ??? *is* actually literal Scala -- it's a function that throws a NotImplementedException, and is delightfully useful.)
Like I said -- it's math jargon. (Not my fault.) It *is* semantically related to "function", but the relationship is fairly complex, having to do with the way types relate to each other.