Re: MDB - Error questions

On Fri, 2002-06-14 at 18:27, Brent Cook wrote: > On 14 Jun 2002, Stig S. Bakken wrote: > > > On Thu, 2002-06-13 at 17:57, Brent Cook wrote: > > > > > > Also, what's the difference between doing this: > > > > > > return PEAR::raiseError(NULL, DB_ERROR_INVALID_DSN, NULL, NULL, 'no valid > > > DBMS driver include path specified', 'MDB_Error', TRUE); > > > > > > and this: > > > > > > return PEAR::raiseError('no valid DBMS driver include path specified', > > > NULL, DB_ERROR_INVALID_DSN, NULL, NULL, 'MDB_Error'); > > > > The first one has an extra parameter, called "skipmsg" which makes > > raiseError skip the error message when creating the error object. > > Instead, the error code becomes the first parameter. This feature is > > useful when you have abstracted error codes like [M]DB and want to base > > error handling on error codes rather than messages. > > > > - Stig > > > > Hmm.. I guess what I really meant was, it appears that there are two ways > to pass a string message; either through the $message field, or through > the $userinfo field. I don't understand the difference between the > $userinfo field and the $message field. > > I also don't understand why raiseError can't just see that the first > parameter is null and skip it, rather than requiring an extra parameter at > the end. According to the docs, $message is a mixed parameter, so it could > represent an error code if needed. So why have the $code parameter at all, > if $message could be a code? Why have another $userinfo field if there can > be a $message field? Would anyone write code that actually expects to read > a string $message returned from as error? It seems that in most cases, an > error should just return a message and a code. Then, you have a code for > fast checking within code, and an error message for the user if you need > that too. > > I understand the parameters currently as: > $message - what went wrong (mixed) > $code - what went wrong (integer) > $userinfo - why it went wrong (string) > > I haven't really used this function beyond PEAR::raiseError("Oops") > because it seems like there are too many of ways to skin a chicken here > and it's not clear to me why. Maybe its for backwards compatibility. It's part backwards compatibility, part a symptom of this being experimented with a lot to find the right model, and part lazyness on my part (the skipmsg param is just lazyness, I admit). The difference between message and userinfo is that message is the text you want to display to end users. Userinfo is generally meant as a place to stick more information that is useful for debugging (userinfo used to be called debuginfo once). - Stig -- Stig Sæther Bakken, Fast Search & Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb