GB>>I suspect this is because it is possible to differentiate between
GB>>error type, and even severity, just through the class of the
GB>>exception.  Perhaps some kind of non-fatal exception equivalent could
GB>>be worked out for 5.1/5.2?

That would be contradiction in terms. Exception means - "somettthing so
bad happened that there's no point to continue locally - the current task
has failed beyond repair". If the caller of the task thinks that this 
sub-task failure is not that bad and the top-level task can still go on, 
it catches the exception and handles it.
>From this point of view, I would use exceptions only to signal a very 
serious error condition - e.g., for DB library it would be DB connection 
missing (since it is not likely for any function to work after that), etc.

GB>>if continue or return was extended to allow returning from a catch to 
GB>>the point of execution after the throw statement, this would of course 
GB>>open a can of worms, but it might solve the issue.  Obviously this would 

I don't think it's possible. Exceptions unroll the stack, and once it's 
unrolled, you can't re-roll it back there. It just doesn't exist anymore. 
And we don't really want to enter the domain of context-switches inside 
PHP.

-- 
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to