Re: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
| From: | Marcus Boerger | Date: | Mon, 16 Feb 2004 21:12:15 +0000 |
| Subject: | Re: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-7891@lists.php.net to get a copy of this message | ||
Hello Ard,
Monday, February 16, 2004, 9:51:51 PM, you wrote:
> Marcus Boerger wrote:
>> as i said before there is a reason for that: I played a long time with
>> exceptions until they became what they are right now. And and attempt
>> to increase the visibility of one of its members can be used to make it
>> SEGV. So i don't want more visibility. Also where is the reason? You can
> Correct me if I'm wrong, but are you saying that the concept of
> extendable Exception methods in general was rejected because its current
> implementation segfaults ? That feels kind of backwards to me ...
You are wrong. The point is i am not willing to risc unstabilites with
exceptions. This is a special class that heavily interacts with the executor
and facilities used even after exceution hence i must be sure several
intenal properties are in an exact and intact form at 100%.
>> read everything just fine and you can overload you exception to print out
>> better formatted output and whatever. The only place where you need to
>> change such member in derived classes is when you are using exceptions
>> as flow control. And duing so is violating exception rule number two. So
>> don't expect this to be changed.
> So we're back to
> try {}
> catch (MyException $e) {
> do_something_with($e->myGetMessage());
> }
> catch (Exception $e) {
> do_something_with($e->getMessage());
> }
> which totally defeats the purpose of subclassing Exception in the first
> place. This has nothing to do 'violating the 10 commandments of exception'.
> Couldn't you replace this with a non-final implementation that calls a
> private (== final in this case) method in the default implementation ?
No those are read access members to private property members. When you lok
at the exception class:
php -r 'reflection_class::export("exception");'
then you'll encounter that you can overload __toString() and the
__construct(). Or in other words you should use 'print $e' or '(string)$e'
or '$e->__toString()'.
--
Best regards,
Marcus mailto:helly@php.net