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

From: Date: Mon, 06 Sep 2004 08:55:26 +0000
Subject: Re: cvs: pear-core /PEAR ErrorStack5.php Warning.php
References: 1  Groups: php.pear.dev php.pear.core 
Request: Send a blank email to pear-dev+get-33238@lists.php.net to get a copy of this message
Greg Beaver wrote: >Warnings can be much more than debugging code. They can be used for >flagging suspect user input (debugging user's usage of your code). >Complex packages can often be used in more than one way, and sometimes >the choice means some input can be either completely valid but quirky, >or invalid and really difficult to find the errors. Which it is often >depends on what the user actually meant by their input. Using >trigger_error() doesn't make any sense here, because you would be >lumping developer-specific information (php errors/notices/warnings) >with user-specific information (input debugging). Using an exception >makes even less sense, as there is no logic error in the program itself >- it can execute the user's wrong intentions with absolutely no conflict. > >This is just one example, if you really force me, I will continue to >come up with them, but the fact is I am right and we can save some time >if you will at least acknowledge that the problem exists so that we can >move on to practical solutions. :) What you describe as warnings looks more like error codes that should be returned from function calls. A warning is here to *warn* the user that he made something wrong. This is to happen as quickly as possible. For example a warning should be triggered when someone uses HTML_Template_IT with $tpl->setVariable('AAA', $value) and the placeholder 'AAA' does not exist. The reason is that setVariable() causes a useless lookup and the user might be believing that this placeholder exists under a different name (a spelling mistake for instance). In this case, it is important to let him know immediately that he made a mistake. With the current PEAR_Error, most of the users will never know that the placeholder does not exist because it is too complicated to get this information: you have be aware that a PEAR_Error might be thrown and write a function to log/display them. With trigger_error(), you get the feedback instantly. If you don't want the feedback, you silence it easily. But most users will want the feedback by default while developing. PEAR_Error is a major design error in this matter. The user input validation example you give is IMO a bad example. While I agree that such a function could return an error object, it doesn't have to be (it shouldn't be) a PEAR_Warning. The type of error object should be left to the package developer because he will always need methods and properties you didn't think of. He might also only want to return true/false, or a simple error code, or a collection of error codes. >> 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. > >The end-user would not have difficulty understanding the API for >PEAR_Warning. It requires learning three methods > >PEAR_Warning::begin() >PEAR_Warning::hasErrors() >PEAR_Warning::end() (or whatever it ends up being called) First look at the API and I am asking myself why you would begin/end a warning ? Then hasErrors(), why would a warning have errors ? What does it mean ? What is an error, and a warning, in that context ? This looks rather unintuitive. So that might be only 3 methods, but I prefer to learn 20 methods I understand than 3 ununderstandable ones. >Advanced users (those with greater needs) would be able to ask more of >the API, and it would be there. trigger_error() is a dead end designed >by procedural coders to help debug the PHP core. The fact that it was >extended to help users is of great value to single-level procedural >code, and of not much use at all to multi-level OO coders who rely on >inheritance and other layerings to organize code. I do not agree. I would in fact be interested to understand what you plan to use a PEAR_Warning object for, please provide a concrete example (the user input validation one represents IMO a design error). And please, do not take it personally, I am just trying to understand why you'd need such a class. At the moment, I think it would cause too much confusion. Bertrand Mansion Mamasam

« previous php.pear.dev (#33238) next »