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

Sergio Carvalho wrote: >Argh, this discussion is jumping lists, and is hell to keep up with. Can >we agree on *one* place to discuss? Ok, I added pear-dev but let's discuss it on pear-core then from now on. >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. Personally, I like to see all warnings immediately in development mode. >Complete recoveries, for example, may >issue warnings that can be safely ignored. This is something I have never tried myself so I cannot say. I think good code should not ignore warnings. It is like coding with -Wall, this usually makes cleaner code. Of course, you might be tempted to ignore a pesky warning because you are using someone else's code where a warning is triggered at the wrong place or for a bad reason but this means a design flaw in the other's code. The solution to this would be to fix the other code. >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. If I understand correctly, you mean that Object1 could tell Object2 that what it wants is wrong and let Object2 decide whether it wants to continue or not ? I am questionning if this is a frequent event. It also looks like Warnings will become tied to program exceution flow and maybe influence it. I fell like this will make things harder for debugging and is not really the purpose of warnings. >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. Take all the time you need :) Bertrand Mansion Mamasam