4 ms·
Two things are getting conflated here. Pointer issues (that I was referring to) and a failure indication. The most trivial pointer issue is a NULL pointer. Th
by TickleSteve 8y ago
Two things are getting conflated here.
Pointer issues (that I was referring to) and a failure indication.
The most trivial pointer issue is a NULL pointer. This is such a trivial issue to catch its hardly even an error, yet people use that case as the exemplar for NULL issues.
detecting (and handling) failures on the other hand is very much different and more in the spirit of what the option-type arguments are about.
In that case, the difficulty is not in detecting the error (that option-types will help with) but the application-level recovery. that is nothing that the language aid you with, its system-design and architecture related.
Basically, its the wrong issue to be thinking about.
- cultus 8y ago>The most trivial pointer issue is a NULL pointer. This is such a trivial issue to catch its hardly even an error, yet people use that case as the exemplar for NULL issues. How can you claim that NPEs are "hardly ever an error." NPEs are the most common error there is! They are indeed easy to catch, but you need to do so nearly everywhere, obscuring the code and introducing potential for error. There is no real, conceptual difference between something like a malloc returning null or a database query result containing a null. It is the same thing. A null absolutely is an error if you don't catch it. By not using Options, it's vastly easier for that to happen.
- TickleSteve 8y ago"hardly even an error" not "hardly ever an error". in other words, NULL pointer errors are a trivial error to deal with.
- taco_emoji 8y agoThey're even easier to deal with if your type system guarantees you can never get them in the first place.
- cultus 8y agoBut yet it is the most common type of bug, even in production. Clearly, it's not that easy to deal with for human programmers. What's the problem with letting the compiler help you?