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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
