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