Re: try..catch

Because it would greatly complicate the implementation for no good reason. Sooner than later, you'd want to have multiple catch blocks possible for the same try statement, to be able to catch different exceptions. I don't want to implement complex logic and feature new semantics. I prefer having the catch code as close as possible to a function call, that would receive the thrown expression as an argument. Then you can use whatever facilities the PHP language gives you, such as switch, if, whatever, to decide what to do with it. Zeev At 00:24 31/08/2000, Mathieu Kooiman (ggInternet) wrote:

Hmm well, why are you so against catching a specific object.. You could go 2 ways.. and I say COULD:-))) try { CauseException(); } catch (...) { if (getbaseclassname($exception)) {} /* whatever */ } /* Your way.. */ try { CauseException(); } catch ( "CapsException" ) { /* short version of above code.. */ } -- CaPS On Thu, 31 Aug 2000, Zeev Suraski wrote: You could throw any expression, including an object of whatever class. The only issue is that the catch statement will always be executed. If you want to handle only certain types of value, e.g., only values which are objects of type CapsExceptionClass, it would be your responsibility to check that the thrown expression (if there was one) belongs to that class, and propagate the exception otherwise. Zeev At 00:15 31/08/2000, Mathieu Kooiman (ggInternet) wrote:

Well it WOULD be nice if you could throw/catch an user-class.. ofcourse.. but I guess thats pushing my luck :-) Nice feature, can't wait to see it:)) On Thu, 31 Aug 2000, Zeev Suraski wrote:

At 00:01 31/08/2000, Mathieu Kooiman (ggInternet) wrote:

I discussed this with you once on #PHP (I'm CaPS) Uhm.. back then you said you didn't want anything like throw() .. Why did you change your mind on that?

What I didn't want is a Java-like, object based catch statement. I

don't

want the catch statement to catch certain types of objects in the

language

level, have several catch statements for the same try, etc. Instead, I believe it's much more important to answer the need to cleanly recover

from

language-level errors on one hand, and give end users the ability

to send

information to the error recovery code in userland code. This, coupled with the ability to selectively propagate the exception in case

your code

fails to handle it (using very simple means with virtually no language-level support), gives you all the power you need, without

tying

the implementation to an object oriented niche, and while keeping

it very

simple. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail:

php-list-admin@lists.php.net

-- Zeev Suraski <zeev@zend.com> http://www.zend.com/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

-- Zeev Suraski <zeev@zend.com> http://www.zend.com/