+1 on using trigger_error() in examples, including in mysql_connect. In my
experience, it needs more exposure to newbies as it is a far more efficient
way of dealing with errors. (And it actually took me a couple years to
discover it! :)

And here is how I would do the code snippet

if (!$conn = mysql_connect($host, $user, $pass)) {
   trigger_error("Cannot connect: ". mysql_error(), E_USER_WARNING);
}

Note that I have it producing a warning instead of an error. That's the way
I do it, at least. ;)

-Roy

----- Original Message -----
From: "Philip Olson" <[EMAIL PROTECTED]>
To: "Gabor Hojtsy" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "'Sara Golemon'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, December 02, 2002 9:08 AM
Subject: Re: [PHP-DOC] Re: error handling [was: ugly cvs subject]


>
> I like the idea of trigger_error() and not using 'die'.  Using
> 'die' in errors in unsexy and rather limiting but yes I remember
> we discussed this before too but it was only part of a huge
> discussion regarding the coding_standards RFC.  I also feel
> 'or' for errors is unsexy and limiting.  How about:
>
> if (!$conn = mysql_connect($host, $user, $pass)) {
>   trigger_error("Cannot connect: ". mysql_error(), E_USER_ERROR);
> }
>
> Or will the !$conn part confuse people?  Regardless, I agree
> if we don't use 'exit', and use trigger_error(), this would be
> a good thing.  We would then update the trigger_error() docs so
> that even ultra newbies can understand them.  Also the error
> would show by default still and be affected by the
> error_reporting function/directive.  This is good.  But, this
> brings up the point of should we use @ in examples, like,
> wouldn't the following be more appropriate?
>
> if (!$conn = @mysql_connect($host, $user, $pass)) {
>   trigger_error("Cannot connect: ".mysql_error(), E_USER_ERROR);
> }
>
> I must admit my ignorance using trigger_error() and friends as
> I use my own but I'll mess with it a bit so I can better add to
> this discussion.  Our examples should assume set_error_handler()
> is not being used but encourage its use and discuss how if the
> database is down how easy it is to show a pretty static html
> page instead.  Maybe in a tutorial ;)
>
> Regards,
> Philip Olson
>
>
>
>
> On Mon, 2 Dec 2002, Gabor Hojtsy wrote:
>
> > > IMHO, I think it's the newbies' decision on how and when to use
> > > functionality available in PHP. I see no problem with the examples in
> > > the documentation reflecting the use of functionality. There are
> > > countless examples in the manual currently which don't use what could
be
> > > considered "best practice", so trying to clutter things up with
> > > debugging logic in this case seems unreasonable (especially when there
> > > is still so much with poor or no reasonable documentation at all).
> >
> > As before, I would vote for trigger_error() insted of die(), because it
> > is "future compatible". So if the programmer introduces a new error
> > handler in his/her program, the errors are handled centrally. I also
> > think, that using trigger_error() instead of die() does not increase the
> > "confusion level" of one example, while introducing some
> > if (DEBUG == true) would increase that... If we stick to using
> > trigger_error() in the examples, users will find it first instead of
> > die(), and using trigger_error() is a much better practice than using
> > die() as it goes through PHPs error handler, so it can be logged, etc.
> >
> > We had a discussion on this before, but never come to a real
> > decicion...
> >
> > Goba
> >
> >
> >
> > --
> > PHP Documentation Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> --
> PHP Documentation Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


---
This mail has been scanned for viruses by AVG.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.419 / Virus Database: 235 - Release Date: 11/19/2002


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to