7 ms·

We have been using Scala lately for a couple of web services that are now running in production at our startup. The difference is huge, because Option[T] refer

We have been using Scala lately for a couple of web services that are now running in production at our startup. The difference is huge, because Option[T] references are type-checked at compile-time. Whenever a reference can be either Some(value) or None, then you are made aware of it and you are also forced to either handle it (by giving a default value, or throwing a better documented exception) or you can simply pass the value along as is and make it somebody else's problem. Option[T] in Scala is also a monadic type, as it implements filter(), map() and flatMap(). It's really easy and effective to work with Option[T]. In comparison with "null", which isn't a value that you can work with other than doing equality tests, None on the other hand is an empty container for which you know at compile-time the type of the value it should contain and in Scala it's also an object that knows how to do filter(), map() and flatMap(). My code is basically free of NullPointerExceptions. This doesn't mean that certain errors can't still be triggered by null pointers, but those errors are better documented. What's better? A NullPointerException or a ConfigSettingMissing("db.url")? Of course, to tell you the truth, Option[T] (or Maybe as it is named in Haskell) is only really useful in a static language. In a dynamic language, such as Clojure, especially if you have multi-methods or something similar, well in such a case Option[T] is less useful. And before you ask, no, Go is not dynamic and people saying that Go feels like a dynamic language, don't really know what they are talking about.

blablabla123 14y ago
>My code is basically free of NullPointerExceptions. This doesn't mean that certain errors can't still be triggered by null pointers, but those errors are better documented. What's better? A NullPointerException or a ConfigSettingMissing("db.url")? Almost always it is a matter of 2 seconds to find the source of a nil pointer error. Given that I would almost never forward raw error messages to the user, I cannot really see a gain. However having a language that combines this Scala feature with Go's exception-free error handling, would be awesome and a true solution that would make software run more reliable and with less crashes.
- Peaker 14y ago
  There was a quote from .NET authors about roughly 50% of the field issues with .NET code being Null Pointer exceptions.
  - blablabla123 14y ago
    Pointers can be null, this is a well-known issue. So when you use pointers, you better check they are not null. Even better it is to have some kind of code convention or pattern that you follow to prevent this. Still I don't understand why you would prefer MyCustomException to crash your catch-less program instead of NullPointerException.
    - Peaker 14y ago
      Ok, you checked your pointer to see it isn't null. Then you passed it to function foo. Which passes it to function bar. Do foo and bar have to check it again? That maintains dead code that will never fire, is untestable, and costs runtime. So you will probably not want to re-check the pointer at every point. However, the compiler doesn't help you here. If you ever decide to call foo or bar from any other point without the NULL check, then you will get a crash. Type safety can solve this. It does not convert "NullPointerException" to "MyCustomException". It converts "NullPointerException" to a compile-time type error (expected Foo, got Maybe Foo. Or: Unhandled pattern in case statement: Nothing). The trick is simply to differentiate between a pointer that is guaranteed to not be null and one that isn't. Then, disallow using a nullable pointer as a regular one and force a check.
      - blablabla123 14y ago
        >Ok, you checked your pointer to see it isn't null. Then you passed it to function foo. Which passes it to function bar. Do foo and bar have to check it again? I guess not, what I'm saying is therefore: if you use a language that does a lot of stuff, you need to find a convention for your project. One may be: check for nil after assigning variables. >costs runtime By all means, no. Anyway, looks like in need to try Scala and see for myself. (Scala installed: check, Hello World: check)

blablabla123 14y ago

>My code is basically free of NullPointerExceptions. This doesn't mean that certain errors can't still be triggered by null pointers, but those errors are better documented. What's better? A NullPointerException or a ConfigSettingMissing("db.url")? Almost always it is a matter of 2 seconds to find the source of a nil pointer error. Given that I would almost never forward raw error messages to the user, I cannot really see a gain. However having a language that combines this Scala feature with Go's exception-free error handling, would be awesome and a true solution that would make software run more reliable and with less crashes.

Peaker 14y ago
There was a quote from .NET authors about roughly 50% of the field issues with .NET code being Null Pointer exceptions.
- blablabla123 14y ago
  Pointers can be null, this is a well-known issue. So when you use pointers, you better check they are not null. Even better it is to have some kind of code convention or pattern that you follow to prevent this. Still I don't understand why you would prefer MyCustomException to crash your catch-less program instead of NullPointerException.
  - Peaker 14y ago
    Ok, you checked your pointer to see it isn't null. Then you passed it to function foo. Which passes it to function bar. Do foo and bar have to check it again? That maintains dead code that will never fire, is untestable, and costs runtime. So you will probably not want to re-check the pointer at every point. However, the compiler doesn't help you here. If you ever decide to call foo or bar from any other point without the NULL check, then you will get a crash. Type safety can solve this. It does not convert "NullPointerException" to "MyCustomException". It converts "NullPointerException" to a compile-time type error (expected Foo, got Maybe Foo. Or: Unhandled pattern in case statement: Nothing). The trick is simply to differentiate between a pointer that is guaranteed to not be null and one that isn't. Then, disallow using a nullable pointer as a regular one and force a check.
    - blablabla123 14y ago
      >Ok, you checked your pointer to see it isn't null. Then you passed it to function foo. Which passes it to function bar. Do foo and bar have to check it again? I guess not, what I'm saying is therefore: if you use a language that does a lot of stuff, you need to find a convention for your project. One may be: check for nil after assigning variables. >costs runtime By all means, no. Anyway, looks like in need to try Scala and see for myself. (Scala installed: check, Hello World: check)