First of all, PHP's object model is most similar to the Java one, so Markus' comparisons make most sense in my eyes.
The object model might be similar to Java (it's a very simple one which I like) but the language is not and *should not be* IMHO. Java got much too bloated and we should *not* make the same mistake with PHP.
(If anyone proposes inner classes in PHP then I'm outta here ;-))
"modern dynamic" languages in that context, as for instance in Python there is no error handling but by using exceptions).
Sorry but that's simply wrong. Python methods can return false or null as much as PHP methods can. It might be a lot more _common_ to use exceptions but there are options. And the exception part is the one I don't like about Python anyway ;-)
Well, your point before was that it's used only about 10 times per library. You shouldn't worry too much about 'heavy constructs', then.
But I do. Because every single PHP programmer now has to learn this new construct for no good reason.
Well, you handle errors in each case. Exceptions just simplify non-local propagation of errors, so I fail to see your point.
Non-local propagation of error is a bogus concept IMHO. Because it only really works in academic examples, everywhere else it just complicated things.
Yeah. And well, people should be able to rely on the idea of 'new' not returning NULL (at least in the common cases, i.e. in the design of the
But they now have to expect new to throw an exception. How is that any better? Sorry, no *I* fail to see your point.
This is interesting. Do you have any explanations of the apparent failure of exceptions for you, or any suggestions on how to improve them (like, by
The concept of non-local handling of errors means you
a) Handle errors where they happen. You don't need exceptions for that
b) Handle errors on a global level (i.e. die). Not feasible in a lot of cases and you don't need exceptions here either
c) You handle errors somewhere inbetween.
Let's look at c): As soon as an exception is not handled at the level of the caller or the method itself but passed through to a level higher up you have to be damn careful not to end up with inconsistencies as the caller function was only executed halfway.
Simplified example where I intentionally handle the exception one level too high:
function add($amount)
{
add_money($amount) and log() or throw exception;
}
function move($amount)
{
$from->add(-$amount);
# It is *not* obvious here that this can fail and execution
# might stop here! Very dangerous!
$to->add($amount);
}function transactions()
{
foreach ($transaction)
try { move($transaction->amount); } catch ...
}The same problem more or less applies if you use traditional error handling (i.e. you would ignore the failure result code of add) but my point is that exceptions _seem_ to help but don't.
I'm sure people will not taking this example apart but I strongly believe that for every solution using exceptions I can come up with a traditional solution which is as easy to use and at least as safe.
- Chris
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
