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:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
