7 ms·

> isn't any different from checking from nulls everywhere You would only check for nulls "everywhere" if all functions could potentially return null. Then, ind

> isn't any different from checking from nulls everywhere You would only check for nulls "everywhere" if all functions could potentially return null. Then, indeed, there is no difference. But (hopefully) not all functions will return null, so you'll probably have at most a single-digit percentage of functions that do. The point is that by using Option, you are explicitly stating "This function can return null", making it impossible for the caller to ignore. If you write it somewhere into the docs, it is indeed easy to overlook. This may not be as relevant when you are only working with your own code, but I find this (and static typing in general) most helpful when dealing with code from someone else, including the libraries one uses.

irahul 14y ago
> But (hopefully) not all functions will return null, so you'll probably have at most a single-digit percentage of functions that do. In a real world API, almost everything that returns an object can return null or throw an exception. > The point is that by using Option, you are explicitly stating "This function can return null", making it impossible for the caller to ignore. Throw an exception if impossible to ignore is the motive. > If you write it somewhere into the docs, it is indeed easy to overlook. It might be overlooked. But is it too much to assume that someone making a call will check the parameters and the return type?
- CookWithMe 14y ago
  There is a fundamental difference between throwing an exception and returning null. From http://en.wikipedia.org/wiki/Exception_handling http://en.wikipedia.org/wiki/Exception_handling: "Exception handling is the process of responding to the occurrence, during computation, of exceptions – anomalous or exceptional situations requiring special processing – often changing the normal flow of program execution." One should throw an exception when an anomalous situation appears, e.g. I can not connect to the database. Whereas returning null / returning an Option means that this case needs to be treated in the normal flow of execution, e.g. asking a Person-object for it's spouse. It is perfectly reasonable that a random person isn't married (so throwing an exception is wrong) but at the same time it should be impossible for the caller to ignore. > It might be overlooked. But is it too much to assume that someone making a call will check the parameters and the return type? http://news.ycombinator.com/item?id=4695587 http://news.ycombinator.com/item?id=4695587 Apparently it is too much to ask, even if the program is performing something super-important for security like SSL.
  - irahul 14y ago
    > It is perfectly reasonable that a random person isn't married (so throwing an exception is wrong) but at the same time it should be impossible for the caller to ignore. The whole discussion started from the claim that Haskell makes the NullPointerException/NoneType non existent. And I am just saying it isn't any different from how you enforce it in any other language - you either handle nulls or throw exceptions. > (so throwing an exception is wrong) I am sorry, but I don't play the "throwing an exception is wrong" game. I use it for actual exceptions, control flow, must-handle scenarios. I don't see how exceptions are defined has to do with how I use it if it makes my program logic clear or translates to my intent. The only reason I think before using exceptions for things which aren't exceptions is the stack which is saved, which most of the times so minuscule that it doesn't matter. Ruby has the best compromise as in it defines catch..throw; most of the languages don't so I resort to using exceptions.
    - CookWithMe 14y ago
      Sorry, but it is not a game, it is a convention that afaik holds true for ALL languages that use exceptions. Using exceptions for control flow is widely accepted as a code smell.
      - irahul 14y ago
        > Sorry, but it is not a game, it is a convention that afaik holds true for ALL languages that use exceptions. Using exceptions for control flow is widely accepted as a code smell. Unless using exceptions either hinders performance(they are expensive but I am yet to see a case where it matters), or makes the control flow incomprehensible, it doesn't matter what is widely accepted. I need a reason for "don't use exceptions because...", and "exceptions for exceptional conditions" or "just because it's widely accepted" doesn't cut it. I am pretty sure you have very strong opinions about goto as well, which I use a lot when using C. It's simply the cleanest way to directly jump to the cleaner instead of convoluting the flow with non-needed flags. Since you are placing much weight on what others deem acceptable, you can look at linux kernel code and Steven's code in Unix Network Programming. Also, exceptions are control flow in every sense of the word, though non-local http://en.wikipedia.org/wiki/Control_flow#Exceptions http://en.wikipedia.org/wiki/Control_flow#Exceptions. I don't know where the notion of exceptions not being control flow came from. Among other examples of exceptions for control flow, Python and Ruby raise StopIteration in their iteration protocol. And in Python, exceptions aren't that much costly.

irahul 14y ago

> But (hopefully) not all functions will return null, so you'll probably have at most a single-digit percentage of functions that do. In a real world API, almost everything that returns an object can return null or throw an exception. > The point is that by using Option, you are explicitly stating "This function can return null", making it impossible for the caller to ignore. Throw an exception if impossible to ignore is the motive. > If you write it somewhere into the docs, it is indeed easy to overlook. It might be overlooked. But is it too much to assume that someone making a call will check the parameters and the return type?

CookWithMe 14y ago
There is a fundamental difference between throwing an exception and returning null. From http://en.wikipedia.org/wiki/Exception_handling http://en.wikipedia.org/wiki/Exception_handling: "Exception handling is the process of responding to the occurrence, during computation, of exceptions – anomalous or exceptional situations requiring special processing – often changing the normal flow of program execution." One should throw an exception when an anomalous situation appears, e.g. I can not connect to the database. Whereas returning null / returning an Option means that this case needs to be treated in the normal flow of execution, e.g. asking a Person-object for it's spouse. It is perfectly reasonable that a random person isn't married (so throwing an exception is wrong) but at the same time it should be impossible for the caller to ignore. > It might be overlooked. But is it too much to assume that someone making a call will check the parameters and the return type? http://news.ycombinator.com/item?id=4695587 http://news.ycombinator.com/item?id=4695587 Apparently it is too much to ask, even if the program is performing something super-important for security like SSL.
- irahul 14y ago
  > It is perfectly reasonable that a random person isn't married (so throwing an exception is wrong) but at the same time it should be impossible for the caller to ignore. The whole discussion started from the claim that Haskell makes the NullPointerException/NoneType non existent. And I am just saying it isn't any different from how you enforce it in any other language - you either handle nulls or throw exceptions. > (so throwing an exception is wrong) I am sorry, but I don't play the "throwing an exception is wrong" game. I use it for actual exceptions, control flow, must-handle scenarios. I don't see how exceptions are defined has to do with how I use it if it makes my program logic clear or translates to my intent. The only reason I think before using exceptions for things which aren't exceptions is the stack which is saved, which most of the times so minuscule that it doesn't matter. Ruby has the best compromise as in it defines catch..throw; most of the languages don't so I resort to using exceptions.
  - CookWithMe 14y ago
    Sorry, but it is not a game, it is a convention that afaik holds true for ALL languages that use exceptions. Using exceptions for control flow is widely accepted as a code smell.
    - irahul 14y ago
      > Sorry, but it is not a game, it is a convention that afaik holds true for ALL languages that use exceptions. Using exceptions for control flow is widely accepted as a code smell. Unless using exceptions either hinders performance(they are expensive but I am yet to see a case where it matters), or makes the control flow incomprehensible, it doesn't matter what is widely accepted. I need a reason for "don't use exceptions because...", and "exceptions for exceptional conditions" or "just because it's widely accepted" doesn't cut it. I am pretty sure you have very strong opinions about goto as well, which I use a lot when using C. It's simply the cleanest way to directly jump to the cleaner instead of convoluting the flow with non-needed flags. Since you are placing much weight on what others deem acceptable, you can look at linux kernel code and Steven's code in Unix Network Programming. Also, exceptions are control flow in every sense of the word, though non-local http://en.wikipedia.org/wiki/Control_flow#Exceptions http://en.wikipedia.org/wiki/Control_flow#Exceptions. I don't know where the notion of exceptions not being control flow came from. Among other examples of exceptions for control flow, Python and Ruby raise StopIteration in their iteration protocol. And in Python, exceptions aren't that much costly.