4 ms·
Gennerally when you have null pointer erros, it is because the developer did not realize that there was the possibility of having a null value at that point in
by gizmo686 13y ago
Gennerally when you have null pointer erros, it is because the developer did not realize that there was the possibility of having a null value at that point in code. Adding this information to the type system allows the developer to know exactly where the issue might occur (and have the compiler complain if it is not handled). Also, in terms of use, maybe has another major advantage over null. Many times in languages with null you see the pattern
if (foo==null) {return null} else {...}
This pattern is handled automaticly by maybe; If you try applying a function to Nothing (maybe's version of null), then the result of that function is also Nothing, even if the function itself was not designed to handle Maybes.
Additionally, as a matter of culture, Haskell programmers rarely throw exceptions.
- wereHamster 13y ago> Additionally, as a matter of culture, Haskell programmers rarely throw exceptions. The writers of unix and other base libraries would disagree. See for example `head`. Or most functions that calls into C where the C function fails with an error. In that case Haskell blows up into your face, and you have to wrap the function invocation in a catch.
- Peaker 13y agoOr replace head with a better function.
- mercurial 13y agoSee the fantastic errors module, which has safe versions of head, etc.
- epsylon 13y agoOr use pattern matching.
- mercurial 13y agoPattern matching is great, you can usually use it instead of head, but you want something like Control.Error.Safe.tryRead to replace other unsafe functions like read.
- tome 13y ago> Additionally, as a matter of culture, Haskell programmers rarely throw exceptions. "Rarely" is relative. Certainly far, far less than other languages, but many otherwise useful libraries are still unfortunately littered with them.