I'd be up for option (B) as well: returning explicit 'false'.
> If those are the choices, I say (B). The reason for the !NULL && !true was
> to maintain as much of PHP's boolean juggling as reasonable. NULL in this
> case being "unreasonable" because functions returning nothing are returning
> N
> I suggest either:
> a) return true if you want the default handler to be called. I don't have
a
> problem with this but people here say it's opposite from other frameworks.
> Are there really so many precedents?
> b) return false (== IS_BOOL && value == 0). This gives a strict but
> reasonable in
So we should probably go for a strict bool(false).
At 03:19 PM 5/30/2004 +0200, Timm Friebe wrote:
On Sun, 2004-05-30 at 14:18, Andi Gutmans wrote:
[...]
> I saw it was already commited before I had a chance to respond. In any
> case, I think that the patch is quite harmless but I don't like the !=
On Sun, 2004-05-30 at 14:18, Andi Gutmans wrote:
[...]
> I saw it was already commited before I had a chance to respond. In any
> case, I think that the patch is quite harmless but I don't like the != NULL
> && !true logic. It's inconsistent with what is considered true/false in PHP
> today. I s
At 09:10 AM 5/28/2004 +0200, Derick Rethans wrote:
On Thu, 27 May 2004, Andrei Zmievski wrote:
> On Thu, 27 May 2004, Sara Golemon wrote:
> > Nah, I know. I'm not saying I'm against it, all I'm saying is that noone
> > will hear any objections from me. It puts an extra tool in the hands
of the
>
Sara Golemon wrote:
> We don't necessarily *have* to. Unless people are explicitly returning a
> false value (as opposed to simply not using return) we can make the
> distinction. Recall that not returning anything is passed as a return
> value
> of NULL. So we could say "If NULL, don't invoke
On Fri, 28 May 2004, Bert Slagter wrote:
> Is this by design?
No, it's fixed in CVS now.
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Bert Slagter wrote:
Now I add a custom errorhandler:
---
function myErrorHandler($errno, $errstr, $errfile, $errline)
{print "We've got a $errno on line $errline in $errfile!";
}
set_error_handler('myErrorHandler');
error_reporting(0);
Hm, i tried manually setting the second para
Derick Rethans wrote:
On Fri, 28 May 2004, Bert Slagter wrote:
> E_STRICT can not be handled you say, can you give a small example script
on that?
regards,
Derick
Of course :)
---
foo = 0;
class Foo
{ var $baz;
function bar()
{
}
}
class Foo2 extends
On Fri, 28 May 2004, Bert Slagter wrote:
> You can't handle all errorlevels with a custom error handler, at the
> moment E_STRICT (why this one by the way?), E_ERROR, E_PARSE,
> E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR and E_COMPILE_WARNING
> cannot be handled. So I can understand that one de
On Thu, 27 May 2004, Andrei Zmievski wrote:
> On Thu, 27 May 2004, Sara Golemon wrote:
> > Nah, I know. I'm not saying I'm against it, all I'm saying is that noone
> > will hear any objections from me. It puts an extra tool in the hands of the
> > user at negligible cost and that's a good thing.
Sara Golemon wrote:
This just means replacing the first line of that patch with:
if (Z_TYPE_P(retval) != IS_NULL && !zend_is_true(retval)) {
This would be fine with me. What do we all thing about feasibility of
this patch going into PHP 5?
+0
No great harm in doing it, but for myself if I'm go
> > Nah, I know. I'm not saying I'm against it, all I'm saying is that
noone
> > will hear any objections from me. It puts an extra tool in the hands of
the
> > user at negligible cost and that's a good thing. All I meant by my
comment
> > was that it's a tool I don't ever see myself (personally
On Thu, 27 May 2004, Sara Golemon wrote:
> Nah, I know. I'm not saying I'm against it, all I'm saying is that noone
> will hear any objections from me. It puts an extra tool in the hands of the
> user at negligible cost and that's a good thing. All I meant by my comment
> was that it's a tool I
> > +0
> >
> > No great harm in doing it, but for myself if I'm going to override the
error
> > handler, I'm going to override the entire error handler.
>
> The need that came up here was that people only wanted to use their error
> handler for their own trigger_error()'ed errors. For normal PHP e
On Thu, 27 May 2004, Sara Golemon wrote:
> > > This just means replacing the first line of that patch with:
> > > if (Z_TYPE_P(retval) != IS_NULL && !zend_is_true(retval)) {
> >
> > This would be fine with me. What do we all thing about feasibility of
> > this patch going into PHP 5?
> >
> +0
> > This just means replacing the first line of that patch with:
> > if (Z_TYPE_P(retval) != IS_NULL && !zend_is_true(retval)) {
>
> This would be fine with me. What do we all thing about feasibility of
> this patch going into PHP 5?
>
+0
No great harm in doing it, but for myself if I'm goin
On Thu, 27 May 2004, Sara Golemon wrote:
> This just means replacing the first line of that patch with:
> if (Z_TYPE_P(retval) != IS_NULL && !zend_is_true(retval)) {
This would be fine with me. What do we all thing about feasibility of
this patch going into PHP 5?
- Andrei
--
PHP Internal
> Of course there is a BC problem. Current error handlers do not have to
> return anything. Once the patch is added, the default handler will all
> of a sudden be invoked, when the developer did not really mean it. I
> realize that the "convention" is to return false if you didn't process
> it, but
On Thu, 27 May 2004, Lenar Lõhmus wrote:
> >> It's backwards compatible with previous functionality, i.e. if you don't
> >> return anything, the default handler does not get invoked.
> >
> > This argument may overrule my preference, of course.
>
> Since error_handler is called from inside PHP eng
Jon Parise wrote:
> The convention(*) for these kinds of things is generally to return
> 'true' when you've handled the message/event and want to discontinue
> further processing. Returning 'false' indicates that you haven't
> handled the event.
You are right. That's how it should be done.
>> I
On Thu, May 27, 2004 at 08:50:48AM -0700, Andrei Zmievski wrote:
> Attached is a small patch that can let you do the following. If you set
> a custom error handler via set_error_handler() but don't want to
> implement all the details of handling every single error level, now you
> can simply handl
Attached is a small patch that can let you do the following. If you set
a custom error handler via set_error_handler() but don't want to
implement all the details of handling every single error level, now you
can simply handle the ones you are interested. Basically, if you return
1 from your error
23 matches
Mail list logo
