If we're talking "failure" an exception is more robust than a return code. I'm NOT telling you which to use simply saying exceptions are more robust. That's a fact.
When no rows are found, returning an empty array results in a simpler API. One Return type is easier to test & deal with than Two return types. I'm not telling you there is an ideal number of return types, simply saying I could accomplish the same thing only 1 return type and I consider that a better solution. I'm saying I would have never even considered the 2 return types unless I was thinking from the "inside" of that method (its implementation) instead of the outside (its API).
Compare:
Code: Select all
foreach($array as $item)
{
echo $item;
}
If the array is empty no harm is done, PHP skips the block.
To:
Code: Select all
if( !$array ) return false;
foreach( $array as $item )
{
echo $item;
}
Same behavior as the first snippet, but more reading.
You see in the latter, the calling code also has to check the return type, and its calling code in return has to check that return type. Sooner or later 90% of your program is a big ball or "return mud", where as an exception can bubble up thru 1,000 layers of code without the programmer having to edit any of those "layers" seasoning them with return statements. Does that mean you should start having methods communicate via exceptions? No of course not. Methods should return data. Inputs & outputs, thats basic. My argument was that 1) true "errors" are better handled with exceptions. 2) An empty array is not an "error" type situation.
PCSpectra wrote:For example, I had (at one point) a checkEmail() validation routine, which would throw exceptions on failure. This worked until I tried to use that same validation routine in an bulk import operation. When an email failed I needed to simply tets for failure, log it, and continue the operation as nothing happened, displaying a log at the end. With exceptions, this code was very difficult to re-enter and so Exceptions were dropped in favour of more traditional error handling.
Exceptions are for exceptional situations. Databases going down, tables crashing, ethernet cords being pulled out of the server, RSS feeds going down, Queries failing, these are exceptional situations. Validating data is not an exceptional situation so you should use the return codes in that regard.
Guys basically we're discussing procedural code vs OOP in regards to error handling. "error codes" being the former, exceptions the latter. This likely stems from our PHP roots and PHP's late adoption of exception when languages like javascript have had them for years before us.
PS > This post is more of a "my 2 cents" thing. I'm not trying to telling Benjamin that the extra complexity wasnt warranted in
his particular case, because obviously I dont know about his
particular code. Im just saying that I consider one return type to be simpler than two, and that in the past tests have helped me find the lowest common denominators in my needs
