3 ms·
What's the problem with returning null from the Integer parse method, provided that you document when this method will return null? The author dismisses this op
by brown9-2 15y ago
What's the problem with returning null from the Integer parse method, provided that you document when this method will return null? The author dismisses this option without much of an explanation.
The aversion to using null for a return type here seems to be a symptom of the same problem as throwing an unchecked exception - when the behavior isn't probably documented, the developer isn't given a chance to know that the return from the method needs to be handled.
But, if you can't trust developers to write or read documentation, then is it really worth it to go out of you way to invent new ways of returning a non-success response from this method? The underlying problem still exists - lack of communication.
- Strilanc 15y agoAgreed. However, sometimes you want more information. Having the method specify why there was an error, so you can give a helpful error message to the user, is desirable.
- aidenn0 15y agoThe problem with returning null is that you end up with an error in one part of the code causing an exception in a later part of the code. Integer i = foo(); //Do a bunch of stuff doSomething(i); is much harder to debug, especially if doSomething() is documented that it is forbidden to call with a null. You now need to find where i came from, which can be non-trivial. If instead you return Either<SomeError,Integer> you now can't call a function that hasn't contracted to either not unbox the value, or deal with the error. It's making the type signature match the documentation, which means that the compiler will help catch programmer error. I don't see how this can be anything but a good thing.