> If there is no need to return a value then I don't do
> so. However, the function is going to process something,
> and surely you should check that the processing has
> succeeded or failed?

This is precisely the point I was going to make. Unless an argument is
p***ed in by reference for manipulation within the function, I can't
think of a reason why you wouldn't want to return a value; true or false
at the very least. You call a function to perform, well, a function. I
would think that you would want to know whether or not the process
within the function was successful, yes?

thnx,
Chris

Hi Chris,

Wednesday, May 30, 2007, 1:17:39 PM, you wrote:

>> If there is no need to return a value then I don't do
>> so. However, the function is going to process something,
>> and surely you should check that the processing has
>> succeeded or failed?

> This is precisely the point I was going to make. Unless an argument is
> p***ed in by reference for manipulation within the function, I can't
> think of a reason why you wouldn't want to return a value; true or false
> at the very least. You call a function to perform, well, a function. I
> would think that you would want to know whether or not the process
> within the function was successful, yes?

Even the most simple function can have more than one failure point
within it. If you aren't handling the errors yourself within the
function, you're returning false all over the place and then having to
do the same checking from whatever called it - duplicated however many
times you call that function from your code.

It's a hideous example, but it's straight out of the PHP manual, so
run with it and indulge me:

$mysqli = new mysqli("localhost", "my_user", "my_p***word", "world");

/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}

If that was wrapped in a function, sticking 'return false' within the
connect_error check is useful why exactly? Equally the fact the
function didn't 'exit' implies it 'returned true' anyway, so why check
it again in whatever called the function in the first place? it has
performed its task, it didn't raise an error.

(I know most of us would never use 'exit' in production code like the
above, so replace it with whatever error handling mechanism you have,
the question above remains the same.)

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

Chris Boget wrote:
>> If there is no need to return a value then I don't do
>> so. However, the function is going to process something,
>> and surely you should check that the processing has
>> succeeded or failed?
>
> This is precisely the point I was going to make. Unless an argument is
> p***ed in by reference for manipulation within the function, I can't
> think of a reason why you wouldn't want to return a value; true or false
> at the very least. You call a function to perform, well, a function. I
> would think that you would want to know whether or not the process
> within the function was successful, yes?
>
> thnx,
> Chris

All depends on the function.

function someFunc(){
$this->counter++;
if($this->counter > 100) $this->counter = 0;
}


Something that simple wont need a return at all.

[snip]
All depends on the function.

function someFunc(){
$this->counter++;
if($this->counter > 100) $this->counter = 0;
}


Something that simple wont need a return at all.
[/snip]

Cl***ically this would need a return, because $this->counter is going to
be less than 100 most of the time, and you may want to return the value
at some point.

Here is the thing (it is akin to all of the holy wars on brackets, etc),
the use of return has been pounded into old-schoolers heads for a long
time, regardless of the Boolean or value returned. It is good style and
it introduces consistency. As far as it being an extra line of code? So
be it! We're not in the day and age where we had to count CPU cycles! If
anyone is designing PHP applications with that level of granularity they
have entered into an amazingly pedantic process for which PHP is not
well suited.

At 5/30/2007 05:41 AM, Richard Davey wrote:
>/* check connection */
>if (mysqli_connect_errno()) {
> printf("Connect failed: %s\n", mysqli_connect_error());
> exit();
>}
>
>If that was wrapped in a function, sticking 'return false' within the
>connect_error check is useful why exactly? Equally the fact the
>function didn't 'exit' implies it 'returned true' anyway, so why check
>it again in whatever called the function in the first place? it has
>performed its task, it didn't raise an error.
>
>(I know most of us would never use 'exit' in production code like the
>above, so replace it with whatever error handling mechanism you have,
>the question above remains the same.)


I demur at your final point: If we don't use exit() and the function
performs non-aborting error handling, it's going to return to the
calling function which in most cases will need to know whether its
child function succeeded or failed.

In most of the applications I write, an SQL error (not merely an
empty result set) indicates more often than not that the parent code
should gracefully withdraw from the process it was attempting to
perform. SQL errors are going to indicate a syntactical error in the
query, a missing table or field, a connection failure, or another
problem serious enough that the developer's attention should be drawn
to it. It's certainly possible in a thoughtfully-written application
for a parent function not to care whether a child SQL query was
successful on this fundamental level, but in most apps we'll want to know.

function parent()
{
lookUpData();
displayData();
}
function lookUpData()
{
set up query;
execute query;
handle errors;
}

where "handle errors" might range from returning a failure flag to
displaying an error message.

In order that displayData() doesn't fall on its face, I would write
the parent function in one of these ways:

if (lookUpData()) displayData();

in which lookUpData() returns true or false, the record set being
p***ed in a global variable (ugh);

or, if displayData() is smart enough to deal intelligently with a
null or empty result set:

$aResultSet = lookUpData();
displayData($aResultSet);
or:
displayData(lookUpData());

in which lookUpData() returns a dataset array that's empty if no
records were found or an error was encountered.

In my programming style, I can't imagine wanting to write this code
in such a way that lookUpData() didn't return some form of success or
error indicator.

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com

Hi Paul,

Wednesday, May 30, 2007, 4:07:00 PM, you wrote:

> I demur at your final point: If we don't use exit() and the function
> performs non-aborting error handling, it's going to return to the
> calling function which in most cases will need to know whether its
> child function succeeded or failed.

> function parent()
> {
> lookUpData();
> displayData();
> }
> function lookUpData()
> {
> set up query;
> execute query;
> handle errors;
> }

> where "handle errors" might range from returning a failure flag to
> displaying an error message.

There's a world of difference between those two events though. If all
'handle errors' does is to return an error flag, then the parent
obviously *needs* to check it. Equally all other functions that ever
call lookUpData() need to duplicate those checks too.

> In order that displayData() doesn't fall on its face, I would write
> the parent function in one of these ways:

> if (lookUpData()) displayData();

That's where our approach differs. If lookUpData falls flat on its
face, my error handler will take over completely, finally resulting in
an 'abortive' event, and never p*** back to the parent. If an error is
of a critical enough nature the system needs to stop. If it's not
critical then the error handling within displayData() would detect it
has nothing to display and error in its own accord.

> In my programming style, I can't imagine wanting to write this code
> in such a way that lookUpData() didn't return some form of success or
> error indicator.

That's a *very* specific example though. My question was do people
place a 'return' statement at the end of **ALL** of their functions,
regardless of what that function actually did. In the code you gave
there is a fair argument both ways, but that isn't always the case.

Here's a piss-poor example off the top of my head:

function parent()
{
display()
}

function display()
{
echo something random
}

In this instance (albeit gloriously simple / useless), would your
display() return true even though it could have never actually failed?
and if it did, do you then care about checking that value in the
parent?

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

At 5/30/2007 08:25 AM, Richard Davey wrote:
> > In order that displayData() doesn't fall on its face, I would write
> > the parent function in one of these ways:
>
> > if (lookUpData()) displayData();
>
>That's where our approach differs. If lookUpData falls flat on its
>face, my error handler will take over completely, finally resulting in
>an 'abortive' event, and never p*** back to the parent. If an error is
>of a critical enough nature the system needs to stop. If it's not
>critical then the error handling within displayData() would detect it
>has nothing to display and error in its own accord.

Hi Richard,

If you write your applications like this then they'll fall over when
something goes wrong -- and here I mean 'fall over' to mean aborting
suddenly with a technical error message. That can be useful to us
during development & debugging but isn't really useful or friendly to
the website visitor.

It also gives every subroutine that handles errors the responsibility
of deciding how to deal with the error -- whether to display it or
not, how to display it, etc. It makes code less portable from one
application to the next.

Consider another model in which subroutines report errors back to the
calling code but don't themselves 'act' on the errors. An error on a
low level can bubble back up to some higher parent level in the
application that knows what to do: whether to display and if so how
and in what human language, whether to email the developer, whether
to close down the application or continue, etc. An English SQL error
message is of little use to a web page in Japanese. It's usually a
mistake to display an SQL query in a public application because it
exposes sensitive details of the database architecture.

For example, we might want to generate the web page even if some part
of its content is unavailable due to the SQL error. This leaves the
visitor with a functional page from which they can navigate normally
even if part of the content is missing. On this high level, the
application might choose to behave nonchalantly as though SQL had
returned an empty recordset and report the hard error to the
webmaster behind the scenes.

This kind of error-handling architecture can be handled in a variety
of ways. One is to maintain a global error structure or cl*** with a
variety of fields that relate to the last error: true/false, error
type, context, query code if applicable, etc. Because a low-level
error may in turn trigger higher-level errors as it bubbles back up,
it may make sense to turn this into an error stack to which each
calling function adds its understanding of the problem as the error
bubbles back up:

0: SQL error ZZZ in "SELECT * FROM `users` ..."
1: Can't query user list YYY
2: No users to display

When a high-level function receives an error state from a called
function, it can (if desired) walk down the stack to learn the
technical origin of the error as well as its implications during the bubble-up.


> > In my programming style, I can't imagine wanting to write this code
> > in such a way that lookUpData() didn't return some form of success or
> > error indicator.
>
>That's a *very* specific example though. My question was do people
>place a 'return' statement at the end of **ALL** of their functions,
>regardless of what that function actually did. In the code you gave
>there is a fair argument both ways, but that isn't always the case.

Absolutely. I agree with most of the respondents to this thread:
return a value only if the caller needs to receive a value
back. Some languages (such as BASIC) distinguish between functions
that return values and subroutines that don't. Because PHP gives
only one type of function to call, with an option whether or not to
return anything, it's clearly up to us to design and impose that
architecture based on our knowledge and preferences.

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com

On Wed, May 30, 2007 7:42 am, Darren Whitlen wrote:
> Chris Boget wrote:
>>> If there is no need to return a value then I don't do
>>> so. However, the function is going to process something,
>>> and surely you should check that the processing has
>>> succeeded or failed?
>>
>> This is precisely the point I was going to make. Unless an argument
>> is
>> p***ed in by reference for manipulation within the function, I can't
>> think of a reason why you wouldn't want to return a value; true or
>> false
>> at the very least. You call a function to perform, well, a
>> function. I
>> would think that you would want to know whether or not the process
>> within the function was successful, yes?

I guess if you're using lots of OOP and try/catch/throw, you'd end up
very rarely having a function return a p***/fail value...

Just depends on coding style, I guess.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

On Wed, May 30, 2007 10:25 am, Richard Davey wrote:
> Hi Paul,
>
> Wednesday, May 30, 2007, 4:07:00 PM, you wrote:
>
>> I demur at your final point: If we don't use exit() and the
>> function
>> performs non-aborting error handling, it's going to return to the
>> calling function which in most cases will need to know whether its
>> child function succeeded or failed.
>
>> function parent()
>> {
>> lookUpData();
>> displayData();
>> }
>> function lookUpData()
>> {
>> set up query;
>> execute query;
>> handle errors;
>> }
>
>> where "handle errors" might range from returning a failure flag to
>> displaying an error message.
>
> There's a world of difference between those two events though. If all
> 'handle errors' does is to return an error flag, then the parent
> obviously *needs* to check it. Equally all other functions that ever
> call lookUpData() need to duplicate those checks too.
>
>> In order that displayData() doesn't fall on its face, I would write
>> the parent function in one of these ways:
>
>> if (lookUpData()) displayData();
>
> That's where our approach differs. If lookUpData falls flat on its
> face, my error handler will take over completely, finally resulting in
> an 'abortive' event, and never p*** back to the parent. If an error is
> of a critical enough nature the system needs to stop. If it's not
> critical then the error handling within displayData() would detect it
> has nothing to display and error in its own accord.

This sounds perfectly reasoanble.

>> In my programming style, I can't imagine wanting to write this code
>> in such a way that lookUpData() didn't return some form of success
>> or
>> error indicator.
>
> That's a *very* specific example though. My question was do people
> place a 'return' statement at the end of **ALL** of their functions,
> regardless of what that function actually did. In the code you gave
> there is a fair argument both ways, but that isn't always the case.
>
> Here's a piss-poor example off the top of my head:
>
> function parent()
> {
> display()
> }
>
> function display()
> {
> echo something random
> }
>
> In this instance (albeit gloriously simple / useless), would your
> display() return true even though it could have never actually failed?
> and if it did, do you then care about checking that value in the
> parent?

Technically, there is no such thing as "could have never actually
failed"...

It's not outside the realm of possibility that:
echo "something random";
could actually fail...

In all the ways I can think of, PHP would never actually return, but
there's no guarantee that won't change under the hood tomorrow...

I'm not saying that every scripter should worry about this; but if you
have a mission-critical application in PHP, you should probably go
ahead and return true/false on success/failure of every function, no
matter how trivial it may seem.

But for your basic website, no, you don't need that level of
robustness -- The Internet itself will cause so many failures that
your lack of error-checking for something that rare will be lost as
"noise" in any sort of statistical error model.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

On Wed, May 30, 2007 12:00 pm, Paul Novitski wrote:
[snip] use the archives

I think there is a LOT of value in bubbling up errors to the
appropriate level of handling, and letting the right layer do the
right job for the error.

HOWEVER: it is not a good idea, imho, to "always" let the errors
bubble up to the outer layer, which is what Paul seemed to have
typed...

The problem with that approach is that you end up being painted into a
corner where your application can do little more than print "It
broke." because the low-level context is not available to the caller
of the function.

The lowest layers of your application should be logging very precise
info about the error for the developer, with code for every possible
error condition you can think of, and hopefully defaults for error
conditions you can't think of.

The middle layers might return a smaller set of common error
codes/messages.

The outer layer might lookup error codes to print suitable end-user
messages, or translate with gettext or...

In an ideal world, the outer layer presents the end user with
something meaningful to them, while providing an error code or unique
identifier that a developer can use to locate the detailed info needed
to fix the problem.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?