type hinting throwing a fatal error

Sebastian Bergmann

21 years ago

Derick Rethans schrieb:

> Opinions?

+1

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Derick Rethans

21 years ago

On Mon, 8 Aug 2005, Sebastian Bergmann wrote:

> Derick Rethans schrieb:
> > Opinions?
>
>  +1

Does that mean you want more opinions? :)

regards,
Derick

Ondrej Ivanič

21 years ago

Derick Rethans wrote:

> Does that mean you want more opinions? :)

Throw an InvalidArgumentException from SPL...

--
Ondrej Ivanic
(ondrej@kmit.sk)

Derick Rethans

21 years ago

On Mon, 8 Aug 2005, Ondrej Ivanič wrote:

> Derick Rethans wrote:
> > Does that mean you want more opinions? :)
>
> Throw an InvalidArgumentException from SPL...

Won't work, SPL can be disabled.

Derick

Sebastian Bergmann

21 years ago

Derick Rethans schrieb:

> Won't work, SPL can be disabled.

The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Tobias Schlitt

21 years ago

Hi Sebastian Bergmann!
On 08/08/05 13:32 you wrote:

>>Won't work, SPL can be disabled.

>  The throw an Exception when SPL disabled and an InvalidArgumentException
>  when it is enabled.

That's senseless when writing applications that shall be version
independant. Just sticking to Exception should be fine.

Regards,

--
Tobias Schlitt - Zend Certified Engineer         GPG Key: 0xA6529579
a passion for php                            http://www.schlitt.info
Like to say "thank you"?    -  http://pear.php.net/wishlist.php/toby

Johannes Schlueter

21 years ago

Hi Toby,

On Monday 08 August 2005 15:04, Tobias Schlitt wrote:

> >  The throw an Exception when SPL disabled and an InvalidArgumentException
> >  when it is enabled.
>
> That's senseless when writing applications that shall be version
> independant. Just sticking to Exception should be fine.

No it is not, in your application you can still simply catch Exception to be
independent of SPL since the InvalidArgumentException class extends the
Exception class. But by using nested Exceptions you can catch them
independently. Else you would have to catch every Exception, parse the error
message or trace to see wether it was a problem while calling the
function/method or some code inside the function/method went wrong.

<?php
function foo() {
$bar = ....;
try {
call_with_wrong_parameter($bar);
} catch (InvalidArgumentException $e) {
// bad function call...
}
}

try {
foo();
} catch (Exception $e) {
// any other exception
}
?>


I'd like to see something like what Sebastian suggested. And imho it wouldn't
really be a bc-break since an uncaught exception is fatal, too.

johannes

Derick Rethans

21 years ago

On Mon, 8 Aug 2005, Johannes Schlueter wrote:

> On Monday 08 August 2005 15:04, Tobias Schlitt wrote:
> > >  The throw an Exception when SPL disabled and an InvalidArgumentException
> > >  when it is enabled.
> >
> > That's senseless when writing applications that shall be version
> > independant. Just sticking to Exception should be fine.
>
> No it is not, in your application you can still simply catch Exception to be
> independent of SPL since the InvalidArgumentException class extends the
> Exception class.

Throwing two different kinds of Exceptions is evil. It should be
consistent, not relying on an external component for it's exceptions. So
it will be a normal Exception. This is a useles branch of this tread -
and it should end now.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Sebastian Bergmann

21 years ago

Derick Rethans schrieb:

> Throwing two different kinds of Exceptions is evil.

Just as evil as allowing SPL to be disabled.

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Marcus Börger

21 years ago

Hello Derick,

Monday, August 8, 2005, 3:00:50 PM, you wrote:

> On Mon, 8 Aug 2005, Johannes Schlueter wrote:

>> On Monday 08 August 2005 15:04, Tobias Schlitt wrote:
>> > >  The throw an Exception when SPL disabled and an InvalidArgumentException
>> > >  when it is enabled.
>> >
>> > That's senseless when writing applications that shall be version
>> > independant. Just sticking to Exception should be fine.
>>
>> No it is not, in your application you can still simply catch Exception to be
>> independent of SPL since the InvalidArgumentException class extends the
>> Exception class.

> Throwing two different kinds of Exceptions is evil. It should be
> consistent, not relying on an external component for it's exceptions. So
> it will be a normal Exception. This is a useles branch of this tread -
> and it should end now.

Throwing a pure Exception is useless. Since it is the nature of Exception
handling to code the reson into the Exception hierarchy. See my other reply
and the comment on moving the exceptions to the engine.

Best regards,
Marcus

Tobias Schlitt

21 years ago

Hi Johannes Schlueter!
On 08/08/05 14:50 you wrote:

>>> The throw an Exception when SPL disabled and an InvalidArgumentException
>>> when it is enabled.

>>That's senseless when writing applications that shall be version
>>independant. Just sticking to Exception should be fine.

> No it is not, in your application you can still simply catch Exception to be
> independent of SPL since the InvalidArgumentException class extends the
> Exception class. But by using nested Exceptions you can catch them
> independently. Else you would have to catch every Exception, parse the error
> message or trace to see wether it was a problem while calling the
> function/method or some code inside the function/method went wrong.

The point is, that it's senseless to have it throw any exception that
can be disabled, when you want to write portable applications. In that
case you still have to stick to catch Exception and have no benefit of
it throwing anything else, when SPL is enabled.

I would pretty much appreciate it having thrown an
InvalidArgumentException, but then this should work everywhere.

Regards,

--
Tobias Schlitt - Zend Certified Engineer         GPG Key: 0xA6529579
a passion for php                            http://www.schlitt.info
Like to say "thank you"?    -  http://pear.php.net/wishlist.php/toby

Jochem Maas

21 years ago

Tobias Schlitt wrote:

> Hi Johannes Schlueter!
> On 08/08/05 14:50 you wrote:
>
>
>>>>The throw an Exception when SPL disabled and an InvalidArgumentException
>>>>when it is enabled.
>
>
>>>That's senseless when writing applications that shall be version
>>>independant. Just sticking to Exception should be fine.
>
>
>>No it is not, in your application you can still simply catch Exception to be
>>independent of SPL since the InvalidArgumentException class extends the
>>Exception class. But by using nested Exceptions you can catch them
>>independently. Else you would have to catch every Exception, parse the error
>>message or trace to see wether it was a problem while calling the
>>function/method or some code inside the function/method went wrong.
>
>
> The point is, that it's senseless to have it throw any exception that
> can be disabled, when you want to write portable applications. In that
> case you still have to stick to catch Exception and have no benefit of
> it throwing anything else, when SPL is enabled.
>
> I would pretty much appreciate it having thrown an
> InvalidArgumentException, but then this should work everywhere.

I guess creating a new special exception (e.g. TypeHintException) that
extends Exception as part of the php core (as opposed to living in SPL)
is a stupid idea?

IMHO btw, semantically, calling it S(tandard)PL and then making it so that
it's not standard (i.e. it's an extension) seems odd.

Marcus Börger

21 years ago

Hello Tobias,

Monday, August 8, 2005, 3:35:28 PM, you wrote:

> Hi Johannes Schlueter!
> On 08/08/05 14:50 you wrote:

>>>> The throw an Exception when SPL disabled and an InvalidArgumentException
>>>> when it is enabled.

>>>That's senseless when writing applications that shall be version
>>>independant. Just sticking to Exception should be fine.

>> No it is not, in your application you can still simply catch Exception to be
>> independent of SPL since the InvalidArgumentException class extends the
>> Exception class. But by using nested Exceptions you can catch them
>> independently. Else you would have to catch every Exception, parse the error
>> message or trace to see wether it was a problem while calling the
>> function/method or some code inside the function/method went wrong.

> The point is, that it's senseless to have it throw any exception that
> can be disabled, when you want to write portable applications. In that
> case you still have to stick to catch Exception and have no benefit of
> it throwing anything else, when SPL is enabled.

> I would pretty much appreciate it having thrown an
> InvalidArgumentException, but then this should work everywhere.

If you plan to support PHP builds without SPL then that most likley means
that you have dropped other built-in default extensions too. Probably
because of their memory space to reduce loading time. In that case you are
not up for portability or have made a major mistake already in the
beginning.

Anyway there is no argument here. If you go for portable apps in the sense
that any extension can be diabled then catching plain Exceptions should be
more than good enough. You cannot expect to have full blown oo support when
you disable the one oo extension.

As a side note we could probably also move all exception declarations from
SPL to the engine but then we'd loose the possibility to support builds
without SPL. At the end of the day i'd even like to drop reflection support
from the engine and move it to a specialized extensions - again - for
speed/memory reasons.

best regards
marcus

Sebastian Bergmann

21 years ago

Derick Rethans schrieb:

> Does that mean you want more opinions? :)

No, I want a (InvalidArgument?)Exception to be thrown when I type-hint
is not met.

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

David Zülke

21 years ago

+1

Michael Sims

21 years ago

Derick Rethans wrote:

> Hei,
>
> currently if you pass a wrong object's type to a typehinted parameter:

[...]

> 	Fatal error: Argument 1 must be an instance of foo in /tmp/foo.php on
> 	line 3
>
> As type hinting is a new OO thing, it might perhaps make some sense to
> make this an exception instead - as this error might also happen for
> dynamic things by people who use the classes you designed. In that
> case having this fatal error to stop the whole application can be
> annoying. Opinions?

As a PHP user, I have to say I wholeheartedly agree, and I'm glad someone is
raising this issue again.  The last time it was seriously discussed:

http://marc.theaimsgroup.com/?l=php-dev&m=104878782529499&w=2

was less than encouraging.

As a user who is trying to write robust code, my biggest issue is not
whether or not a type hint violation throws an exception, but whether or not
it results in an error than I can trap for.  An exception would be great,
obviously, but I'd be just as happy with an E_WARNING, so at the very least
my custom error handler can catch this.  As you have pointed out, it's
currently a fatal error so a user-defined error handler is not called.

I don't typically comb through my server's php error logs, since I mainly
depend on my custom error handler to let me know when one of my applications
is having problems.  Because of this I have been forced to avoid using type
hints and I've actually implemented by own function to simulate type hints,
like so:

/* @param SomeObject $foo */
public function someMethod($foo) {
checkArgType($foo, 'SomeObject');
}

checkArgType() throws an exception if $foo isn't instanceof 'SomeObject'.

I would MUCH rather use type hints here.  They're cleaner from a
documentation standpoint and the wtf factor is much lower.  Unfortunately I
can't as long as type hint violations are fatal.

So, I would be very happy if type hint violations either threw and exception
OR triggered an E_WARNING.  As Wez pointed out in
http://marc.theaimsgroup.com/?l=php-dev&m=104911187824684&w=2, currently if
you pass the wrong number of arguments to a function/method you get an
E_WARNING (not a fatal error), so I don't see why type hint violations
shouldn't be treated similarly.  It would increase their value and utility
immensely...

Markus Fischer

21 years ago

Derick Rethans wrote:

> As type hinting is a new OO thing, it might perhaps make some sense to
> make this an exception instead - as this error might also happen for
> dynamic things by people who use the classes you designed. In that case
> having this fatal error to stop the whole application can be annoying.
> Opinions?

+1 on throwing an exception.

- Markus

Andrey Hristov

21 years ago

Hmm,
I was complaining about inusaability ot type hinting because of this fatal
errors but nobody seems heard me :(. One better do a check in the code than
risking a fatal error which is unstoppable...
I call this showstopper if we say that we are proud with the type-hinting.

Andrey


Quoting Derick Rethans <derick@php.net>:

Derick Rethans

21 years ago

On Mon, 8 Aug 2005, Andrey Hristov wrote:

>  Hmm,
> I was complaining about inusaability ot type hinting because of this fatal
> errors but nobody seems heard me :(. One better do a check in the code than
> risking a fatal error which is unstoppable...
> I call this showstopper if we say that we are proud with the type-hinting.

Proof-of-concept patch is here:
http://files.derickrethans.nl/patches/typehint-reference-2005-08-08.diff.txt
(I need to clean up the message allocation stuff)

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Zeev Suraski

21 years ago

I don't think that's a good idea, regardless of implementation issues.

Calling to a function with the wrong arguments is something that should be
dealt with when developing the application, not at runtime.  I think that
throwing exceptions in all sorts of places encourages people to write
'exception-oriented' apps, which is very messy.  Type hinting is also not
exactly an OO thing, it's an object thing, and there's a difference.  PHP
is filling up with a lot of builtin classes, as well as infrastructure
classes, that actually simplify the lives of users, without them having to
have a clue about object orientation.  Some examples that come to mind are
SimpleXML, the SOAP classes and PDO.  On a long enough timescale -
everybody using PHP will be using objects, and many (if not most) of them
will be using them in procedural apps.  I see a big negative point in
forcibly introducing these people to the concept of exceptions.

I believe we mentioned once the possibility of adding another error level,
which is fatal - but still catchable by set_error_handler().  That is a
good idea (which we should be doing either way).

Zeev

At 12:50 08/08/2005, Derick Rethans wrote:

Tobias Schlitt

21 years ago

Hi Zeev Suraski!
On 08/10/05 17:30 you wrote:

> I think
> that throwing exceptions in all sorts of places encourages people to
> write 'exception-oriented' apps, which is very messy.

Sorry, but I consider that statement wrong. We are still talking about
PHP and a not caught exception will result into a fatal error. Therefore
you do not force anyone to actually write 'exception-oriented' apps.

> I believe we mentioned once the possibility of adding another error
> level, which is fatal - but still catchable by set_error_handler().

What actually would be the same as having a try block around your
application.

> That is a good idea (which we should be doing either way).

I definitly agree here, but it does not make sense for type hinting.

But heaving the type hints throwing an exception  is a really nice
feature for large applications, where you are often not sure, which
parts of the application will call a function or even worse you're not
sure with which objects you act (because of utilizing multiple different
libraries, written be even more different people). Having an exception
thrown in that case enables you to run surrounded, independant modules
to finish their work gracefully instead of shutting down the whole
request gracefully.

The actual implementation of type hints does not allow them to be used
in this case, because having a coding error in just 1 module will screw
up all other modules, where just 1 is broken.

Regards,
Toby

--
Tobias Schlitt - Zend Certified Engineer         GPG Key: 0xA6529579
a passion for php                            http://www.schlitt.info
Like to say "thank you"?    -  http://pear.php.net/wishlist.php/toby

Andrey Hristov

21 years ago

I concur!

Andrey

Tobias Schlitt wrote:

Zeev Suraski

21 years ago

At 02:28 11/08/2005, Tobias Schlitt wrote:

>Hi Zeev Suraski!
>On 08/10/05 17:30 you wrote:
>
> > I think
> > that throwing exceptions in all sorts of places encourages people to
> > write 'exception-oriented' apps, which is very messy.
>
>Sorry, but I consider that statement wrong. We are still talking about
>PHP and a not caught exception will result into a fatal error. Therefore
>you do not force anyone to actually write 'exception-oriented' apps.

Did I say 'force'?  I said 'encourage'.  The text of an uncaught exception
mentions, well, an uncaught exception.  What the heck does that mean?  What
is an exception and why did it run away?  It would encourage people to
start learning what exceptions are, a non trivial concept at the least, and
one of the first things they'll see is that they can trap them with try/catch.

> > I believe we mentioned once the possibility of adding another error
> > level, which is fatal - but still catchable by set_error_handler().
>
>What actually would be the same as having a try block around your
>application.

Right, which is infinitely better.  It does not encourage (<-- not force)
you to write code that recovers from exceptions, but rather - a trap-all
just-in-case-something-goes-really-wrong error message.

> > That is a good idea (which we should be doing either way).
>
>I definitly agree here, but it does not make sense for type hinting.
>
>But heaving the type hints throwing an exception  is a really nice
>feature for large applications, where you are often not sure, which
>parts of the application will call a function or even worse you're not
>sure with which objects you act (because of utilizing multiple different
>libraries, written be even more different people). Having an exception
>thrown in that case enables you to run surrounded, independant modules
>to finish their work gracefully instead of shutting down the whole
>request gracefully.
>
>The actual implementation of type hints does not allow them to be used
>in this case, because having a coding error in just 1 module will screw
>up all other modules, where just 1 is broken.

Well, like I said - sorry, but I consider that statement wrong :)  I
definitely think that this type of error is the one that is caught during
development, and not during runtime, and is fixed as soon as it's
found.  Writing advanced 'let's try to call this, and if it fails do that'
is exactly the kind of stuff I'm trying to avoid.  If you really want to do
that - you can use the ultra advanced approach and use reflection.

Zeev

Christian Schneider

21 years ago

Zeev Suraski wrote:

>> > I believe we mentioned once the possibility of adding another error
>> > level, which is fatal - but still catchable by set_error_handler().
>>
>> What actually would be the same as having a try block around your
>> application.
>
> Right, which is infinitely better.  It does not encourage (<-- not
> force) you to write code that recovers from exceptions, but rather - a
> trap-all just-in-case-something-goes-really-wrong error message.

Catch-alls are bad but... There is an even worse case: People start
abusing exceptions for flow control/ normal operation like replacing
something like "if ($obj) foo($obj)" with "try { foo($obj); } catch
(Exception $e) {}" because the error message mentions exceptions and/or
because they just learned about it and think it's cool.

If you guys decide to go forward and use an exception for type hinting
(which is a tad more powerful, agreed) then at least make the exception
message very clear that the caller of the function should make sure he
passes the proper object type to the function, NOT that if should be
wrapped in try/catch.

My $.02,
- Chris

Derick Rethans

21 years ago

On Wed, 10 Aug 2005, Zeev Suraski wrote:

> Calling to a function with the wrong arguments is something that should be
> dealt with when developing the application, not at runtime.  I think that
> throwing exceptions in all sorts of places encourages people to write
> 'exception-oriented' apps, which is very messy.  Type hinting is also not
> exactly an OO thing, it's an object thing, and there's a difference.  PHP is
> filling up with a lot of builtin classes, as well as infrastructure classes,
> that actually simplify the lives of users, without them having to have a clue
> about object orientation.  Some examples that come to mind are SimpleXML, the
> SOAP classes and PDO.  On a long enough timescale - everybody using PHP will
> be using objects, and many (if not most) of them will be using them in
> procedural apps.  I see a big negative point in forcibly introducing these
> people to the concept of exceptions.

I agree a 100% here.

> I believe we mentioned once the possibility of adding another error level,
> which is fatal - but still catchable by set_error_handler().  That is a good
> idea (which we should be doing either way).

That would work well. I just want the type hints to be catchable.

regards,
Derick

Derick Rethans

21 years ago

On Thu, 11 Aug 2005, Derick Rethans wrote:

> > I believe we mentioned once the possibility of adding another error level,
> > which is fatal - but still catchable by set_error_handler().  That is a good
> > idea (which we should be doing either way).
>
> That would work well. I just want the type hints to be catchable.

Except that it shouldn't be able to stop the application. The reason for
this is that Unit Testing on this stuff should still work, and you can't
always anticipate what your users do with your libraries. If a user
does something wrong in a third party module to your application,
and pass a wrong opbject to one of your utility classes, when we do
not want the whole application to stop immediately, as it might be
just a sub-part of you application which is very possible to ignore
for the full working of your application. This is why
I first suggested an exception, so that the application can continue.
Although in *my* opinion the application just should blow up, other
people disagree with me here.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Lukas Smith

21 years ago

Derick Rethans wrote:

> On Thu, 11 Aug 2005, Derick Rethans wrote:
>
>
>>>I believe we mentioned once the possibility of adding another error level,
>>>which is fatal - but still catchable by set_error_handler().  That is a good
>>>idea (which we should be doing either way).
>>
>>That would work well. I just want the type hints to be catchable.
>
>
> Except that it shouldn't be able to stop the application. The reason for
> this is that Unit Testing on this stuff should still work, and you can't

Well UnitTests should always be run in a separate process, so that you
can infact to proper edge (or even over the edge) testing.

regards,
Lukas

Derick Rethans

21 years ago

On Thu, 11 Aug 2005, Lukas Smith wrote:

> Derick Rethans wrote:
> > On Thu, 11 Aug 2005, Derick Rethans wrote:
> >
> > > >I believe we mentioned once the possibility of adding another
> > > >error level, which is fatal - but still catchable by
> > > >set_error_handler().  That is a good idea (which we should be
> > > >doing either way).
> > >
> > >That would work well. I just want the type hints to be catchable.
> >
> > Except that it shouldn't be able to stop the application. The reason for
> > this is that Unit Testing on this stuff should still work, and you can't
>
> Well UnitTests should always be run in a separate process, so that you can
> infact to proper edge (or even over the edge) testing.

I agree, but none of the Unit Test frameworks (except php-tests) do
this. I don't think I should be rewriting yet another one.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Zeev Suraski

21 years ago

At 11:03 11/08/2005, Derick Rethans wrote:

>On Thu, 11 Aug 2005, Derick Rethans wrote:
>
> > > I believe we mentioned once the possibility of adding another error
> level,
> > > which is fatal - but still catchable by set_error_handler().  That is
> a good
> > > idea (which we should be doing either way).
> >
> > That would work well. I just want the type hints to be catchable.
>
>Except that it shouldn't be able to stop the application. The reason for
>this is that Unit Testing on this stuff should still work, and you can't
>always anticipate what your users do with your libraries. If a user
>does something wrong in a third party module to your application,
>and pass a wrong opbject to one of your utility classes, when we do
>not want the whole application to stop immediately, as it might be
>just a sub-part of you application which is very possible to ignore
>for the full working of your application. This is why
>I first suggested an exception, so that the application can continue.
>Although in *my* opinion the application just should blow up, other
>people disagree with me here.

You mean it shouldn't be able to stop the application, or that the
application should be able to prevent this error from stopping it?  If it's
the latter, then it would be possible.  If it's the former, then I don't
quite understand...

Zeev

Derick Rethans

21 years ago

On Thu, 11 Aug 2005, Zeev Suraski wrote:

> You mean it shouldn't be able to stop the application, or that the application
> should be able to prevent this error from stopping it?  If it's the latter,
> then it would be possible.  If it's the former, then I don't quite
> understand...

The latter is fine too.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Derick Rethans

21 years ago

On Thu, 11 Aug 2005, Derick Rethans wrote:

> On Thu, 11 Aug 2005, Zeev Suraski wrote:
>
> > You mean it shouldn't be able to stop the application, or that the application
> > should be able to prevent this error from stopping it?  If it's the latter,
> > then it would be possible.  If it's the former, then I don't quite
> > understand...
>
> The latter is fine too.

Okay, shall I give it a go as implementation? It seems most are for
another type of error that are fatal if not "handled" in the user error
handler. There is just one thing... how do we signal it back from the
handler? Currently there is no defined return value for the user defined
error handler. I suggest that if you return "false" from the user
defined error handler than that signals that PHP should handle the error
(and this stop the application in case the new error type was thrown).

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Andrei Zmievski

21 years ago

I thought I made that patch a while ago?

zend.c:
if (retval) {
if (Z_TYPE_P(retval) == IS_BOOL && Z_LVAL_P(retval)
== 0) {
zend_error_cb(type, error_filename,
error_lineno, format, args);
}
zval_ptr_dtor(&retval);
}

-Andrei

On Aug 22, 2005, at 2:53 AM, Derick Rethans wrote:

Derick Rethans

21 years ago

On Mon, 22 Aug 2005, Andrei Zmievski wrote:

> I thought I made that patch a while ago?
>
> zend.c:
>                if (retval) {
>                     if (Z_TYPE_P(retval) == IS_BOOL && Z_LVAL_P(retval) == 0)
> {
>                         zend_error_cb(type, error_filename, error_lineno,
> format, args);
>                     }
>                     zval_ptr_dtor(&retval);
>                 }

Ah, great. I didn't know this. This doesn't solve the problem of the
catchable fatals though. I've a patch for that ready, just need to do
some testing.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Zeev Suraski

21 years ago

At 12:53 22/08/2005, Derick Rethans wrote:

>On Thu, 11 Aug 2005, Derick Rethans wrote:
>
> > On Thu, 11 Aug 2005, Zeev Suraski wrote:
> >
> > > You mean it shouldn't be able to stop the application, or that the
> application
> > > should be able to prevent this error from stopping it?  If it's the
> latter,
> > > then it would be possible.  If it's the former, then I don't quite
> > > understand...
> >
> > The latter is fine too.
>
>Okay, shall I give it a go as implementation?

Yep.

>It seems most are for
>another type of error that are fatal if not "handled" in the user error
>handler. There is just one thing... how do we signal it back from the
>handler? Currently there is no defined return value for the user defined
>error handler. I suggest that if you return "false" from the user
>defined error handler than that signals that PHP should handle the error
>(and this stop the application in case the new error type was thrown).

I'm not exactly following.  If you want to stop the application, why
wouldn't you simply exit()?

Zeev

Derick Rethans

21 years ago

On Mon, 22 Aug 2005, Zeev Suraski wrote:

> >It seems most are for
> >another type of error that are fatal if not "handled" in the user error
> >handler. There is just one thing... how do we signal it back from the
> >handler? Currently there is no defined return value for the user defined
> >error handler. I suggest that if you return "false" from the user
> >defined error handler than that signals that PHP should handle the error
> >(and this stop the application in case the new error type was thrown).
>
> I'm not exactly following.  If you want to stop the application, why wouldn't
> you simply exit()?

I *don't* want to stop it :)

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Zeev Suraski

21 years ago

At 14:34 22/08/2005, Derick Rethans wrote:

>On Mon, 22 Aug 2005, Zeev Suraski wrote:
>
> > >It seems most are for
> > >another type of error that are fatal if not "handled" in the user error
> > >handler. There is just one thing... how do we signal it back from the
> > >handler? Currently there is no defined return value for the user defined
> > >error handler. I suggest that if you return "false" from the user
> > >defined error handler than that signals that PHP should handle the error
> > >(and this stop the application in case the new error type was thrown).
> >
> > I'm not exactly following.  If you want to stop the application, why
> wouldn't
> > you simply exit()?
>
>I *don't* want to stop it :)

So in that case, the implementation in zend_error_cb() should simply call
the user error handler if it's available, or treat it as if it's E_ERROR if
there is no user error handler.

Zeev

Marcus Börger

21 years ago

Hello Zeev,

Monday, August 22, 2005, 1:38:54 PM, you wrote:

> At 14:34 22/08/2005, Derick Rethans wrote:
>>On Mon, 22 Aug 2005, Zeev Suraski wrote:
>>
>> > >It seems most are for
>> > >another type of error that are fatal if not "handled" in the user error
>> > >handler. There is just one thing... how do we signal it back from the
>> > >handler? Currently there is no defined return value for the user defined
>> > >error handler. I suggest that if you return "false" from the user
>> > >defined error handler than that signals that PHP should handle the error
>> > >(and this stop the application in case the new error type was thrown).
>> >
>> > I'm not exactly following.  If you want to stop the application, why
>> wouldn't
>> > you simply exit()?
>>
>>I *don't* want to stop it :)

> So in that case, the implementation in zend_error_cb() should simply call
> the user error handler if it's available, or treat it as if it's E_ERROR if
> there is no user error handler.

Isn't an E_ERROR by default good enough or do you want exceptions here
always? In the former case it might be better to have a new error level
E_HINT. In the latter case maybe it might be a good idea to move the
default exceptions from ext/spl to the engine and have a 'Hint' whatever
exception class derived from RunTimeException.


Best regards,
Marcus

Zeev Suraski

21 years ago

At 20:53 22/08/2005, Marcus Boerger wrote:

> > So in that case, the implementation in zend_error_cb() should simply call
> > the user error handler if it's available, or treat it as if it's E_ERROR if
> > there is no user error handler.
>
>Isn't an E_ERROR by default good enough or do you want exceptions here
>always?

I'm not sure what happened, but I don't want exceptions at all, let alone
always :)

>  In the former case it might be better to have a new error level
>E_HINT. In the latter case maybe it might be a good idea to move the
>default exceptions from ext/spl to the engine and have a 'Hint' whatever
>exception class derived from RunTimeException.

One of us is missing something, or we're not talking about the same thing
at all.

I'm talking about allowing type hints to be trappable by users, without
complicating them with exceptions.  I'm proposing a new error level, which
behaves like E_ERROR, except it can be caught using a userland error
handler, for those cases where the engine/PHP are in a stable state.

Zeev

George Schlossnagle

21 years ago

On Aug 22, 2005, at 3:50 PM, Zeev Suraski wrote:

> At 20:53 22/08/2005, Marcus Boerger wrote:
>
>> > So in that case, the implementation in zend_error_cb() should
>> simply call
>> > the user error handler if it's available, or treat it as if it's
>> E_ERROR if
>> > there is no user error handler.
>>
>> Isn't an E_ERROR by default good enough or do you want exceptions
>> here
>> always?
>>
>
> I'm not sure what happened, but I don't want exceptions at all, let
> alone always :)
>
>
>>  In the former case it might be better to have a new error level
>> E_HINT. In the latter case maybe it might be a good idea to move the
>> default exceptions from ext/spl to the engine and have a 'Hint'
>> whatever
>> exception class derived from RunTimeException.
>>
>
> One of us is missing something, or we're not talking about the same
> thing at all.
>
> I'm talking about allowing type hints to be trappable by users,
> without complicating them with exceptions.  I'm proposing a new
> error level, which behaves like E_ERROR, except it can be caught
> using a userland error handler, for those cases where the engine/
> PHP are in a stable state.

This sounds good to me.  We talked about this briefly a year or so
ago, in reference to being able to convert E_ERROR errors to
exceptions in an extension.

George

Derick Rethans

21 years ago

On Mon, 22 Aug 2005, George Schlossnagle wrote:

> > I'm talking about allowing type hints to be trappable by users, without
> > complicating them with exceptions.  I'm proposing a new error level, which
> > behaves like E_ERROR, except it can be caught using a userland error
> > handler, for those cases where the engine/PHP are in a stable state.
>
> This sounds good to me.  We talked about this briefly a year or so ago, in
> reference to being able to convert E_ERROR errors to exceptions in an
> extension.

Right, my current patch allows you do to that for the new "E_CATCHABLE"
error. I don't like the name though, so we need to come up with a better
one (sorry Zeev :) .

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Zeev Suraski

21 years ago

At 23:02 22/08/2005, Derick Rethans wrote:

>On Mon, 22 Aug 2005, George Schlossnagle wrote:
>
> > > I'm talking about allowing type hints to be trappable by users, without
> > > complicating them with exceptions.  I'm proposing a new error level,
> which
> > > behaves like E_ERROR, except it can be caught using a userland error
> > > handler, for those cases where the engine/PHP are in a stable state.
> >
> > This sounds good to me.  We talked about this briefly a year or so ago, in
> > reference to being able to convert E_ERROR errors to exceptions in an
> > extension.
>
>Right, my current patch allows you do to that for the new "E_CATCHABLE"
>error. I don't like the name though, so we need to come up with a better
>one (sorry Zeev :) .

E_CATCHABLE is definitely not good since it should be clear that it's
otherwise a fatal error.  I'm all for finding something more, well, catchy
than E_CATCHABLE_ERROR, but if worse comes to worst...

Zeev

Zeev Suraski

21 years ago

At 22:54 22/08/2005, George Schlossnagle wrote:

>This sounds good to me.  We talked about this briefly a year or so
>ago, in reference to being able to convert E_ERROR errors to
>exceptions in an extension.

Exactly.

Zeev

Markus Fischer

21 years ago

Zeev Suraski wrote:

> At 20:53 22/08/2005, Marcus Boerger wrote:
>
>> > So in that case, the implementation in zend_error_cb() should simply
>> call
>> > the user error handler if it's available, or treat it as if it's
>> E_ERROR if
>> > there is no user error handler.
>>
>> Isn't an E_ERROR by default good enough or do you want exceptions here
>> always?
>
>
> I'm not sure what happened, but I don't want exceptions at all, let
> alone always :)

Sorry to jump into the middle. I've read the thread but I don't
understand why for the average user it should make a difference whether
it's a real fatal error or just an uncaught exception.

My point is that both way of errors will have the same goal for the
average user: execution of script is stopped and the reason is shown to
the user. Actually an exception has more information attached to it
which I personally consider a plus.

Let alone the point that type hinting is something average users are not
likely to use anyway. And when they get in touch with it through a third
party PHP library, even than an exception would be more useful because
it displays the code flow of the library the user has no relation to;
another plus to me.

Now these points are not specific to the type hinting discussion here
actually. Any kind of error which may be fatal to the user but does not
leave the engine in an unpredictable state may be an exception. It is
the same functionality plus has more useful information attached to it.
I hope with these sentences I don't start another "convert all errors to
exceptions thread", this is clearly beyond what I'm trying to say.

An the other hand, people who want to use these feature have the option
to use it.

In the end it's not loss of functionality in any way. Both parties
(average users and not-so-average users) would benefit.

thanks for listening,
- Markus