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

From: 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:
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.
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.
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.
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.
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
« previous php.pear.dev (#33243) next »