|
Posted by Tony Marston on 09/02/06 09:04
It is definitely the better way to include error checking, but only for
fatal errors. When it comes to database errors it is FAR better to use the
error message which is generated by the DBMS engine and access it via a
customised error handler. So in your code you would have something like:
$result = mysql_query($this->query, $this->dbconnect) or
trigger_error($this, E_USER_ERROR);
For details on how to customise the error handler take a look at
http://www.tonymarston.co.uk/php-mysql/errorhandler.html
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
"lawrence k" <lkrubner@geocities.com> wrote in message
news:1157171356.224445.135390@e3g2000cwe.googlegroups.com...
>
> I've made it habit to check all returns in my code, and usually, on
> most projects, I'll have an error function that reports error messages
> to some central location. I recently worked on a project where someone
> suggested to me I was spending too much time writing error messages,
> and that I was therefore missing the benefit of using a scripting
> language. The idea, apparently, is that the PHP interpreter writes all
> the error messages that are needed, and that I shouldn't write such
> code myself. I was given the impression that if I needed extensive
> error checking, or strict typing, then I should use a real language,
> like Java, but if I'm going to use a scripting language like PHP or
> Ruby, then I should leave errors to the interpreter, since the whole
> point of using scripting languages is speed of development. Has anyone
> else heard this argument, and do you agree with it? I'm wondering how
> other PHP programmers handle error messages. Check everything or leave
> it to the PHP interpreter to tell you when there is an error?
>
> Which of these two functions is better, the one with error checking or
> the one without?
>
> function getWeblogEntries() {
> $query = "SELECT * FROM weblogs";
> $result = mysql_query($query);
> $howManyWeblogEntries = mysql_num_rows($result);
> for ($i=0; $i < $howManyWeblogEntries; $i++) {
> $row = getRow($result);
> extract($row);
> echo "<h1>$headline</h1>";
> echo "<h7>$date</h7>";
> echo "<div class=\"mainContent\">$mainContent</div>";
> }
> }
>
>
>
> function getWeblogEntries() {
> $query = "SELECT * FROM weblogs";
> $result = mysql_query($query);
> if ($result) {
> $howManyWeblogEntries = mysql_num_rows($result);
> for ($i=0; $i < $howManyWeblogEntries; $i++) {
> $row = getRow($result);
> if (is_array($row)) {
> extract($row);
> echo "<h1>$headline</h1>";
> echo "<h7>$date</h7>";
> echo "<div class=\"mainContent\">$mainContent</div>";
> } else {
> reportError("In getWeblogEntries, the function getRow
> failed to return an array on the $i iteration.");
> }
> }
> } else {
> reportError("In getWeblogEntries, the query to the database
> failed.");
> }
> }
>
>
>
> My own feeling, obviously, is that it is better to error check
> everything, and to write extensive comments everywhere. I've taken over
> PHP projects, started by other programmers, that had no error checking
> and no comments, and such projects are always a big pain in the neck. I
> lose time playing Sherlock Holmes, trying to track down where a
> function's parameter first originates and why it's in use. I'd rather
> have a comment on it, and error message for when the wrong thing is
> passed in. Obviously this slows development. Is there any concensus
> among developers about what is the best approach? I think whatever is
> cheapest for the client should be considered the best approach, but it
> seems to me cheapest-in-the-short-term is quite different from
> cheapest-in-the-long-term.
>
[Back to original message]
|