But SRSLY, a function return should NEVER be used to test if it worked in production code. For that, we have Exceptions!!

In the same way a function consumer may not know if a bad developed function worked if it has no return value, a bad developer may also not bother to test it and use the “error sign value” as if workable data. With Exception we assure consumer will know that something bad happened and there’s no returned data to use, or that his function will also return with the same Exception.

If you expect to do something and it fails, and you know that (an expected error, handled by the software!), and it can’t be bypassed, just throw a meaningful Exception and document it. PHP is bad on handling Exceptions because it doesn’t allow functions to enforce exceptions they may throw and it’s not compiled, therefore we lose a valuable moment to be warned if we don’t catch or rethrow them.

Recently I had to work on a software that was developed by outsource team. It was total junk, even though developed in Java+Servlet, it was full of errors and all Exceptions were being presented by Tomcat to user. It’s VERY frustrating when noobs let unhandled Exceptions show unformatted to users.

Case in point, in case you’ve not read this yet:

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

Exceptions do not help your method chaining example. If I call $inst->foo()->bar()->bat()->baz(), and I catch an exception, where did it occur? I have to do a significant amount of work reading the data held in the exception instance to find out what failed. (This is one reason I really don’t like methods returning instances, *especially* when those methods might throw an exception.)

In fact, the only times I’ve heard people complain about return values from functions is because they don’t want to do error handling. This crops up on the Go mailing list every so often: people get unexpected behavior, they paste their code, and they handle no errors. In fact, I find the Go error handling solution rather elegant: http://blog.golang.org/2011/07/error-handling-and-go.html

Fundamentally, if you are not following the documented API and checking for possible errors, you deserve what you get. If a function or method can return null, don’t complain when your code breaks because you didn’t check for it. That’s *your* fault.

1. “A return value can be used to tell if the function behaved properly.”

Well, yes, but usually a return value is used to return the result of a function. And it is up to the developer to decide which value should be returned if something went wrong. PHP functions usually return FALSE instead of something like a resource or integer values, and it can be hard to differentiate (strpos() == false is wrong).

On the other hand, if it isn’t a function, then it has no return value. These things used to be called procedures in other languages.

2. “A null return value can’t easily be tested.”

Wrong.

if (is_null($returnValue)) { /* failure code */ }
if (isset($returnValue)) { /* works as well */ }

$this->assertNull($returnValue); // unit testing

Testing for NULL is as easy as testing for FALSE. If the developer decides that instead of a usable value the function will return NULL in case of errors, this can easily be used.

3. “Returning a null value breaks fluent interfaces.”

This is no valid argument because any method inside fluent interfaces always must return it’s own object again. There simply is no decision whether or not NULL is the return value for failure. Reporting errors in OOP usually is done by throwing exceptions. Reporting emptiness is done by using empty or nonfunctional objects of the same interface.

I think this article needs more updating. The last part on what to return is ok, but the introductory discussion is misleading and presents the wrong arguments.

The question is: “What is a proper return value in case there is no obvious return value?” And the cases are a) dealing with errors, b) dealing with emptiness and c) default behavior when unconfigured.

I only want to add (slightly off topic):

- Fluent interfaces for setters are bad practice because they encourage anaemic models. When you see $thing->setFoo($foo)->setBar($bar) , it often means you may need to encapsulate those as one operation doSomething($foo, $bar), where ‘doSomething’ is a verb that has actual meaning in your domain.

- Fluent interfaces are very useful though for builders. The Doctrine QueryBuilder or the PHPUnit MockBuilder for example would be very annoying without fluent interfaces.

1. Fluent interfaces are much more than method chaining and, despite your opinion, they are widely used to improve the readability of the code.

2. Said that, it doesn’t mean we must use them everywhere. But sometimes they’re pretty useful:

“Can you give me the sugar?” — “Anything else?” — “And a cup?” — “Anything else?”

I think this is a better approach, which makes sense.

In my opinion, solutions to this problem range from bad to worse. The real issue is “old school” domain modeling – like many domain-related issues, this one largely disappears when you stick to modern DDD practices. That, is don’t model $user->country as a relation, because the Country object isn’t part of the User aggregate in the first place – it’s outside the transaction boundary of any reasonable User transaction, so only the Country ID is part of the actual User aggregate, and should be modeled as such.

So now instead of $user->country->name, you get something like $countries->getOrDefault($user->country_id)->name, where $countries is your Country repository. You’re now explicitly saying “give me the Country or a Country null-object”, which is what you want in a scenario where you’re displaying the Country name. In some other scenario (e.g. business logic rather than display purposes) you may want a NULL rather than a null-object, or you may even want an Exception thrown – you indicate this in consumer-code by explicitly calling get(), getOrDefault(), getOrNull(), or whatever is appropriate in each case.

Classic domain modeling (and for that matter most modern ORM) teaches us to ignore transaction boundaries and model everything as monolithic graphs – issues like this one is just one of many issues that go away when you model your domain strictly respecting transaction boundaries. Yes, it takes a little more code – but model-consumer code becomes a lot more transparent, and you can more elegantly handle necessary deviations from the way you generally treat relations, on a case-by-case basis.

DDD practices desperately need to gain footing in the PHP world.

If a method doesn’t have to tell something, it _shouldn’t_ tell something.

This fluent-interface just provokes messy code, because it leads to longest method call chains, where nobody can follow, which method returns what and why. Especially “why”. I say “setSomething()” and the method returns itself? Do you always say youre name, when something tells you something.

“Can you give me the sugar?” — “Brandon” — “And a cup?” — “Brandon”

And exactly this is how a fluent-interface looks like ;)

The return value of a method (or a function) should not be used for error conditions. If you can’t and don’t want to use exceptions, use a by-reference parameter for either the “returned value” ($error = foo($arg1, $arg2, $value)) or the error ($value = foo($arg1, $arg2, $error)). This allow you to detect errors without checking the “returned value”.

function getCommentLinkById($id) {
$row = $db->find($id);
if(!$row) {
return false;
}
return $row['link'];
}

In my opinion, using exceptions is often a much easier way to indicate a ‘failure’.