RE: [PEAR-DEV] Mod 10 for Payment package?

On 17 Sep 2003 at 11:27, Joe Stump wrote: > I guess I like my error checking to be even more complex. I usually > return PEAR_Error instances and use them as such: > > $result = Validate::creditcard('20987280976262'); > if(PEAR::isError($result)) > { > die($result->getMessage()); > } > > I can change the default behavior though ... I've had discussion about Pierre with this (and will include him in CC of this email to please comment on it). But as far as I understood him he didn't want to have any pear-errors or something in the basic Validate::anything()-functions - maybe in the objects directly like Finance_IBAN, Finance_creditcard or some others which may follow. This leads us to a general discussion (again and again) about errorHandling, signalling etc., right? Pierre, how would you expect this to be handled in Validate (and maybe some other packages)? With the current approach I've implemented after discussion with you (in the CVS-part for IBAN)? Or with pear-error-objects as Joe proposed? And since Tomas has also taken part in this discussion maybe he could also contribute a thought from his sight. I think we should find a general agreement that shouldn't be limited just to Validate. Stefan > -----Original Message----- > From: Tomas V.V.Cox [mailto:cox@idecnet.com] > Sent: Wednesday, September 17, 2003 6:24 AM > To: Pierre-Alain Joye > Cc: Stefan Neufeind; pear-dev@lists.php.net; joe@joestump.net; > makler+pear@man.torun.pl > Subject: Re: [PEAR-DEV] Mod 10 for Payment package? > > > > On Wednesday, September 17, 2003 10:49, Pierre-Alain Joye wrote: > > > On Wed, 17 Sep 2003 10:41:29 +0200 > > "Stefan Neufeind" <stefan@neufeind.net> wrote: > > >> For sure your contributions are always welcome. But maybe Joe could > >> have a look at it, compare it with his ideas and if he has further > >> contributions / checks / ... could streamline all the up-coming > >> ideas? > > > Yeah go ahead to commit changes according to our discussion. Once > > you are ready mail me, then I'll launch a new alpha release. > > > It will be easier for you to get feedbacks. > > > One important point about Validate is it will always return > > true/false. It is the main idea behind it. However subclasses may > > provide more informations about what is wrong in a given data. > > Tomas, agreed? > > If there will be functions returning error codes, I guess that would > be better to normalize this situation to all functions. > > If error codes starts from -1 to -n, the look will be: > > Simple check: > > if (Validate::foo('bar') < 0) { > die("invalid 'bar'"); > } > > Complex check: > > $error = Validate::foo('bar'); > if ($error == VALIDATE_FOO_TOO_SHORT) { > die("'$bar' was too short"); > // or even provide error messages > die(Validate::getMessage(VALIDATE_FOO_TOO_SHORT)); > // other idea > die(Validate::getLastErrorMessage()); > } > > I'd use VALIDATE_<FUNCTION>_MSG for the convention. The objective of > the class was simplicity of checking, but I agree that many people > need or want to have precise info about the error. > > It's up to you Pierre, I'm just giving ideas :)