Re: Re: cvs: pear-core /PEAR ErrorStack5.php Warning.php

Argh, this discussion is jumping lists, and is hell to keep up with. Can we agree on *one* place to discuss? Bertrand Mansion wrote:

I tend to agree with Alan here. IMO, warnings are something that help you debug your code so no matter so it is important that you see them immediately when you are developing and can log them when in production. And this is something already supported by PHP natively (in the ini file).

Almost true. As I see it after the work on the Exception RFC, Warnings signal error recoveries -- stuff ranging from malformed input and precondition check failures to exception recovery on handling. The big problems start when error recoveries produce side-effects -- what I called incomplete recoveries in the RFC. These can lead to cascades of warnings and ultimately an error. You may not want to see all warnings, even in development mode, but just the set of warnings that may be related to a specific exception. Complete recoveries, for example, may issue warnings that can be safely ignored. Because of incomplete recoveries, and layered designs, you fall into much the same problems as in error handling without exceptions. Stack-bottom packages don't have enough information to decide if a recovery is a warning or an error, and stack-top packages need a mechanism to receive the warning. So far, you could perfectly use trigger_error and set_error_handler, were we not using Exceptions alongside it. It seems really awkward to use trigger_error, because you lose much of the great stuff about exceptions -- namely hierarchical classification and call stack data. And we need that information in order to upgrade Warnings into Exceptions where needed. Into the bundle, Greg added a transaction mechanism into warnings, inherited from PEAR_ErrorStack. Greg's transaction-oriented design is a great idea, because it goes beyond adding exception-like features to warnings, and aggregates warnings that can are probably related. When debugging this should be more informative that the pure list of warnings. You can probably look at the warning set generated in a transaction and quickly deduce that Warning 1 caused warning 3 ultimately leading to the Exception that borked your program. Having said this, I still must reserve some time this week to play with the code. I have some doubts as to how PEAR_Warning handles sub-transactions (bound to happen in layered designs) and I'd like to get rid of the PEAR_Warning::begin call -- in error handling, the lighter the better.

I think we should really concentrate on PEAR_Exception and use trigger_error() for warnings. This would make everything lighter and easier to understand for the end-user than requiring him to deal with a new API. Bertrand Mansion Mamasam

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc