Re: MDB - Error questions
| From: | Brent Cook | Date: | Fri, 14 Jun 2002 16:27:22 +0000 |
| Subject: | Re: MDB - Error questions | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-7028@lists.php.net to get a copy of this message | ||
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.
- Brent