Re: Suggestion for fetchInto

Stig Sæther Bakken wrote: > [...] > > > > > > Whether a function that raises an error returns the error object or > > > not should never vary, that only leads to confusion, obscure bugs and > > > grinding of teeth. Besides, if you set the default error handler to > > > for example PEAR_ERROR_PRINT, you will still want the object back. > > > > Sure, but we can't expect from people to set an error handler. > > So maybe we should change the default to PEAR_ERROR_TRIGGER or > PEAR_ERROR_DIE then? [...] > Well, I'm very sceptical to changing the API, especially when it > breaks consistency, which I think not returning errors in fetchRow and > fetchInto does. If you insist on having the "dumb and simple" > behaviour, it's better to do it with two new methods. If we can save people to write extra code, the behaviour could be named: "smart and simple" :) What about this: 1) Change Default Pear _DB_ errors to print, die or trigger (as you said). My vote is for TRIGGER (personally I prefer DIE, but is not a good practice to abort inside a lib). I don't know if this change should break the actual people code (the only change they would need to do is set the error handler to RETURN). People would thank us, if we also return the debug info. 2) Change DB_OK to 1. At least this change could save fetchInto :) With these little changes we'll have safe and simple row fetching (hey and also developers won't need to check always for a error object) without more changes (as is everywhere "documented" -> phpbuilder, your conf in Apache CON, my tutorial): while ($row = $res->fetchrow()) and while ($res->fetchInto($row)) Tomas V.V.Cox