Re: Mail_IMAP 2.0.0 alpha 1

David Costa wrote:

I still don't think you understand. PEAR_ErrorStack should not wrap or replace exceptions. Instead, it is there for warnings and notices that should not be fatal if not caught.

That's it's purpose, and yes, PEAR_ErrorStack is the best we have _for that purpose_. Same with PEAR_Exception being the best solution for handling exceptions within PEAR. If your package does not need notices or warnings, you of course don't need to use ErrorStack ;-)

okay, then we are all fine ;) I don't need notices or warnings at this stage.

Yes, I think that this is probably true of most packages. It's been awhile since I've written something where I needed to raise warnings. PHP engine raises a lot of warnings that really ought to be exceptions when in an application context. For example, if a database update fails chances are your application cares. If not, you're doing some weird development :) (and of course you can set up your exception handling to ignore failure when desired). Personally I still like trigger_error() when there are warnings, as applications have to handle PHP warnings/notices already, so just adding some more to the mix doesn't hurt. I think that PEAR_Exception is perfect for fatal stuff in PHP5. It provides logging abilities via very generic callbacks. Realistically, I've also found that there are relatively few high-level points where exceptions are finally caught & dealt with (internally an exception may be caught and re-thrown with a little more context info, but I don't need each throw logged). I generally just put my own log() call in my top-level catch blocks. Even after Tomas added that to PEAR_Execption & I though "oh, neat" I still haven't had an occasion where Exceptions warranted a logging observer. But it is a neat option. Anyway, for WARNINGS / NOTICES, I think that [something like] ErrorStack is great. What I was really trying to suggest is some sort of interface that PHP5 classes could implement so that calling code could be aware that there were warnings contained in that class. E.g. // my code calling $obj wants to know about // any warnings for some reason: if($obj instanceof IRaiseWarnings) { $warnings = $obj->getWarnings(); // do something fun with those warnings } So, I think everyone agrees :) I don't think you should require PEAR_ErrorStack for error handling because most PHP5 classes won't need it. For WARNINGS & NOTICES it's certainly a good approach. Java, which obviously uses Exceptions only, uses conventions of similar stack-based warning systems. For example in the JDBC classes you have getWarnings() methods for the major classes (Connection, Statement, ResultSet). In that case objects derived from Exceptions are pushed on as warnings. Not that we should "be like Java", but the model clearly works -- and lets users ignore the warnings, which is the point. Also, using Exception-derived classes is convenient because those classes embody attributes that are just as useful for warnings. Hans