Exception / trace member

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