trigger_error() does direct the new scripter in a more rational error
handling direction than a series of die() calls. Moreover, the first time
they want to output errors to logs or send administrative emails they'll
appreciate having something like this. +1 for using trigger_error()
instead of die().
I also detest the use of or constructs to call functions on failure, +1 on
that too.
Unfortunately, we havn't answered the original concern. Is it proper to
be dumping detailed error messages in the examples. I say yes. Showing
the scripter how to do basic debugging until their program is working will
help them learn faster.
Of course, this does introduce the problem of scripters leaving the
verbose error messages in their code when they're ready for production.
Should set_error_handler()'s documentation be updated at the same time to
reflect switching between debug and production modes? (Production mode
being the time to supress NOTICE and perhaps WARNING errors)
-Pollita
> +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
>>
>>
>>
>>
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
