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