4 ms·

As mentioned in the replies, nullable type references. https://hinchman-amanda.medium.com/null-pointer-references-the-billion-dollar-mistake-1e616534d485 https

As mentioned in the replies, nullable type references. https://hinchman-amanda.medium.com/null-pointer-references-the-billion-dollar-mistake-1e616534d485 https://hinchman-amanda.medium.com/null-pointer-references-t...

vips7L 6y ago
I personally prefer null and exceptions over Option types and Results. The former provides felixbility within OOP if you use a lot of interfaces. I haven't struggled with null pointers since I started programming a long time ago.
- rualca 6y ago
  > I personally prefer null and exceptions over Option types and Results. Personal preferences and all, I feel the comparison between Result and exceptions is somewhere between misguided and miopic. The Result type and exceptions do not serve the same purpose. Exceptions are not intended to handle control flow, and the Result type is not intended to handle exceptional behavior. Moreover, they are not mutually exclusive. To provide an example, a Result type would be returned by a database query, and it would return Ok if an element was found or return a Fail if either an element didn't existed or was not valid. Meanwhile an exception would be thrown if a memory allocation error happened somewhere.
  - vips7L 6y ago
    At the end of the day they're both used to report errors.
    - rualca 6y ago
      They really aren't. Exceptions handle exceptional events that potentially lead to a shutdown, while the Result monad only reports.... Results. I mean, not finding a record in a database is not an error, nor is getting a response to a HTTP request with status code 3xx or a 404 or a 409.
      - joshuamorton 6y ago
        > I mean, not finding a record in a database is not an error, nor is getting a response to a HTTP request with status code 3xx or a 404 or a 409. But in some languages, exceptions would be used to handle these cases. Admittedly, those languages are usually higher level than C/C++ (but both Java and Python would probably find it common to handle a 3xx or a 404 or a missing row with an exception) At a high level, I think the important thing is that funct() -> Result<T> and func() -> T that may throw/raise an exception are basically equivalent. Result may require slightly more explicitness at (at least) one call site, but ultimately both allow you to return a T, or report some non-T result, in a structured way. The only difference is that exceptions force you to handle the result explicitly (although that may just mean a single call to value! or VALUE_OR_DIE, or whatever the "get the T or segfault/panic" method is). In this way, I really do think checked exceptions are highly analogous to Result types. Implementations may have different performance tradeoffs, but those aren't implicit in the choice of exception vs. result.

vips7L 6y ago

I personally prefer null and exceptions over Option types and Results. The former provides felixbility within OOP if you use a lot of interfaces. I haven't struggled with null pointers since I started programming a long time ago.

rualca 6y ago
> I personally prefer null and exceptions over Option types and Results. Personal preferences and all, I feel the comparison between Result and exceptions is somewhere between misguided and miopic. The Result type and exceptions do not serve the same purpose. Exceptions are not intended to handle control flow, and the Result type is not intended to handle exceptional behavior. Moreover, they are not mutually exclusive. To provide an example, a Result type would be returned by a database query, and it would return Ok if an element was found or return a Fail if either an element didn't existed or was not valid. Meanwhile an exception would be thrown if a memory allocation error happened somewhere.
- vips7L 6y ago
  At the end of the day they're both used to report errors.
  - rualca 6y ago
    They really aren't. Exceptions handle exceptional events that potentially lead to a shutdown, while the Result monad only reports.... Results. I mean, not finding a record in a database is not an error, nor is getting a response to a HTTP request with status code 3xx or a 404 or a 409.
    - joshuamorton 6y ago
      > I mean, not finding a record in a database is not an error, nor is getting a response to a HTTP request with status code 3xx or a 404 or a 409. But in some languages, exceptions would be used to handle these cases. Admittedly, those languages are usually higher level than C/C++ (but both Java and Python would probably find it common to handle a 3xx or a 404 or a missing row with an exception) At a high level, I think the important thing is that funct() -> Result<T> and func() -> T that may throw/raise an exception are basically equivalent. Result may require slightly more explicitness at (at least) one call site, but ultimately both allow you to return a T, or report some non-T result, in a structured way. The only difference is that exceptions force you to handle the result explicitly (although that may just mean a single call to value! or VALUE_OR_DIE, or whatever the "get the T or segfault/panic" method is). In this way, I really do think checked exceptions are highly analogous to Result types. Implementations may have different performance tradeoffs, but those aren't implicit in the choice of exception vs. result.