type hinting throwing a fatal error

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

+1

-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Monday, August 08, 2005 11:50 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] type hinting throwing a fatal error

Hei,

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

derick@kossu:~$ cat /tmp/foo.php
<?php
class foo {
function bar(foo $a)
{
}
}

$a = new foo;
$a->bar(new stdClass);
?>
derick@kossu:~$ php /tmp/foo.php

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?

Derick

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...

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

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:

Hei,

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

derick@kossu:~$ cat /tmp/foo.php
<?php
class foo {
function bar(foo $a)
{
}
}

$a = new foo;
$a->bar(new stdClass);
?>
derick@kossu:~$ php /tmp/foo.php

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?

Derick

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:

Hei,

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

    derick@kossu:~$ cat /tmp/foo.php
    <?php
    class foo {
            function bar(foo $a)
            {
            }
    }

    $a = new foo;
    $a->bar(new stdClass);
    ?>
    derick@kossu:~$ php /tmp/foo.php

    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?

Derick