Hello Stephane,
> if this is really the case, well then i am the one to blame. I'll have a
> look.
i looked into it - you were right - and i fixed it. Could you please test
current HEAD to verify i have fixed all issues? That would give me a better
feeling. And thanks for noticing this.
marcus
> Thursday, January 22, 2004, 3:46:13 PM, you wrote:
>> The current implementation of class Exception has a private "trace"
>> member, which is used to store the backtrace. But if you throw an
>> exception of a derived class of Exception, print_r() displays an empty
>> "trace:private" member, as well as a "trace" (public) member that really
>> holds the backtrace.
>> I deduce that the backtrace is executed/stored at the derived class
>> level, explaining why a new public member is created.
>> Curriously, I have also noticed that "getTrace()" returns the public
>> one, not the private one as expected.
>> This is not to report a bug, but to ask you not to fix it as it was
>> intended ("trace" member as private). Indeed I use this "feature" (being
>> able to modify the trace member) to hide an intermediate call:
>> <?
>> class SystemException extends Exception {
>> function __construct($message, $code) {
>> parent::__construct($message, $code);
>> // Hide trace of handler() call.
>> array_splice($this->trace, 0, 1);
>> $this->file = $this->trace[0]['file'];
>> $this->line = $this->trace[0]['line'];
>> }
>> static function handler($code, $message) {
>> throw new SystemException($message, $code);
>> }
>> }
>> set_error_handler(array('SystemException', 'handler'));
?>>>
>> That way, the reported error focuses on the real file and line, not on
>> the uninteresting intermediate handler call.
>> In the current Exception class implementation, if both the "trace"
>> member is private and getTrace() is final, it would be impossible to
>> override the default behaviour. As a result, we would do our own exception
>> base class, which goes against code reuse: need to redo all the things
>> already done, just because the proposed class is not too open.
>> A second consequence, is that each time you use code you've got from
>> "outside", it could implement its own exception base class, not using the
>> provided Exception. If so, we won't be able to write generic code that
>> guaranties to catch all exceptions (C++ "catch(...)" or Java "finally" not
>> implemented in PHP5, so need to specify a class for catch).
>> The last point suggests me that PHP should guaranty that all thrown
>> exceptions derive from Exception. It could be done in 2 ways:
>> 1/ a fatal error when executing "throw new ...".
>> Problem: it's not easy to simulate all error conditions, so we may
>> deliver code that was never tested on all its "throw" branches. As a
>> result, the script will stop on a fatal error, even though it was intented
>> to catch and handle exceptions in a clean way.
>> 2/ even if the class is not explicitly derived from Exception, throwing
>> it will make it derived from Exception.
>> Problem: an object of such a class will be an instance of Exception only after
>> being thrown.
>> The 2nd is my prefered one, even if I understand it could not be so easy to
>> implement.
>> One word about private and final: I don't think it's good programming
>> to use them, except for security reasons. Not using them allows classes to
>> be easily extended, in different directions, which is the goal of OOP.
>> Moreover, all members should be protected, not public, and accessed
>> through (virtual) methods, which guaranties that everything can be
>> overriden if needed.
>> Regards,
>> Stephane
> --
> Best regards,
> Marcus mailto:[EMAIL PROTECTED]
--
Best regards,
Marcus mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
