3 ms·
This does not seem to be fixing null checks. It seems to be fixing lack of proper error handling. The problem is not that you have to check for null, the proble
by NateDad 13y ago
This does not seem to be fixing null checks. It seems to be fixing lack of proper error handling. The problem is not that you have to check for null, the problem is that you don't know if null is a valid value, and even if you know it's not, you don't know why the method failed. This is simply a lack of a channel for returning errors.
There are a lot of ways to fix this problem... Many modern languages use exceptions for this. Some languages use out parameters. Languages with multiple return values often return a value and an error. They're all essentially equivalent, and yes, they're all better than just returning null.
I don't really see a difference between:
data_source.person(id) do |person|
person.phone_number = phone_number
data_source.update_person person
end
and
data_source.updatePhoneNumber(id, phone_number)
The latter one encapsulates the find, the error handling, and the setting. Yes, you might have a null check in there. Or you might have a try/catch, or you might be checking an out value or a multiply returned error value.... there's really no difference. You've changed the API to signify that the person might not exist and this function might not actually do anything. And that's fine, if that's fine. However, most of the time, if I go to set someone's phone number, I want to know if the system thinks that person doesn't exist.
- qznc 13y agoThat first code might just be the implementation of updatePhoneNumber. You are just moving the problem.
- NateDad 13y agoSomewhere there has to be a check to see if the person with that id exists, and if so, change its phone number. It could be a SQL statement running in the db, it could be a null check, or a try/catch or it could be inside data_source.person(id) do |person| I'm just saying, it has nothing to do with nulls and everything to do with error handling. This teller pattern handles errors by implicitly ignoring them. If that's your intended behavior, that's fine. It also evidently has some nice language support in ruby, and that's cool. But it doesn't really "solve" any "problem". Mostly because there's no problem in the first place. Error handling is not a problem, it's a fact of life in software development.
- dasil003 13y agoExceptions for null handling? I admit there's room for healthy debate about using exceptions for flow control in various situations, but for null handling it sounds like an absolute nightmare. Instead of considering null at each point it might occur in the code, you have to consider all the possible places a null value might be stacked above you.
- NateDad 13y agoExceptions for error handling... this is just error handling, that was my point. Returning a sentinel value (null) is just one (very suboptimal) way of handling an error. Instead of dataSource.getPersonById(id) returning null, it could throw a NotFoundException. This is better because it's a specific error (as opposed to a MalformedIdException, for example).
- Fistandantilus 13y agoExceptions can be used in strategic places to ensure that a value returned can never be null. Ex: public Person findPerson(String name) { for (Person p : personList) { if (p.getName().equals(name)) { return p; } } throw new PersonNotFoundException(name); } We can be sure that the return value of findPerson will never be null, as it must either return the correct value or throw an exception. Whether this is better, worse, or the same as a null check is debatable.