Re: Re: PEAR_ErrorStack renaming question

Greg Beaver wrote: >Not only do I plan (currently) to implement PEAR_Warning as code lifted >from PEAR_ErrorStack, I plan to make them use the same stack, if >possible, so that moving from PEAR_ErrorStack to PEAR_Warning (for those >who are re-factoring php4/php5 apps to php5-only) will be painless for >both the developers and the end-users. > >Actually, I am patient enough to implement this not in a wiki, but in >code first. By this, I mean that I will change the implementation over >and over again when people take the time to look at it and make >suggestions. If I have a fault, it is that I often don't see the logic >in someone's suggestions until I've slept on them, so for all of you who >have been on the receiving end (and may be in the future) of "I don't >think that is the right way" and then seen your suggestions show up in >CVS the next day, I apologize now :). > >Basically, once there is a code possibility, I think the RFC will be a >piece of cake. Greg, I have updated the PEAR_Exception code with a new getReason() method. A reason holds a detailled message why the exception happened (exception class, exception message, file, line). This new method allows for two returned formats first as a string, second as an array. This way, you can present this information as you prefer. In this context, a cause is another exception object that caused this exception to happen. So the difference between a cause and a reason should be clear. Maybe method _signal() could use the reason instead of the exception message. The reason is always more complete and contains the message. The updated code is here: <http://www.mamasam.com/pear/Exception.phps> Let me know when you have some code ready for PEAR_Warning. Bertrand Mansion Mamasam