Re: cvs: pear-core /PEAR ErrorStack5.php Warning.php
| From: | Sergio Carvalho | Date: | Mon, 06 Sep 2004 10:22:37 +0000 |
| Subject: | Re: cvs: pear-core /PEAR ErrorStack5.php Warning.php | ||
| References: | 1 2 | Groups: | php.pear.dev php.pear.core |
| Request: | Send a blank email to pear-dev+get-33243@lists.php.net to get a copy of this message | ||
Bertrand Mansion wrote:
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
Personally, I like to see all warnings immediately in development mode.Good code will ignore warnings in production environments. Per definition, they are not error conditions, so the program will try to complete without disturbing the user. Now, imagine a code run firing a sequence of warnings and then an Exception. I'd like the warnings to be *part* of the exception, since there's a good chance one of these will be the cause.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.
I'll reuse the example of an incomplete recovery from the Exception RFC (the third code block in that section): http://wiki.ciaweb.net/yawiki/index.php?area=PEAR_Dev&page=RfcExceptionUse#toc32 The example is one of a Config object defaulting to some predefined values when failing the connection to the config storage. This behaviour is probably ok in 80% of the package's clients. For the remaining 20% that won't allow default values, the warning is provided as a form of detecting the incomplete recovery allowing for the warning to be upgraded to an exception. You can guess this is pretty common.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.I don't understand this point. Cheers, Sérgio P.S. Is pear-core present in the newsgroup server? My Thunderbird won't list it :-/. I've subscribed pear-core for the time being, but I prefer an NNTP interface.
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc