Why muting error messages is considered harmful for a programmer?

In the other topic I’ve been asked recently, why a code like this

if (function_call) {
    //do something
{
    $connection->error;
    return  false; 
}

is considered harmful.

Indeed, for a layman or a learner, there is no direct harm, such as security vulnerability or a program crash.
This code will just silently mute the error message as though there was no error at all. What’s so wrong with it?

The answer can come only from experience.
Error messages are like pain for a human. It’s a signal telling you that something goes wrong.
Imagine you had no sense of pain. What would happen if you put our hand on fire? You wouldn’t jerk it out immediately but probably notice the disaster when it will be too late. The same goes with error messages in programs. As long as you can see them, you can fix a problem. But if you do nothing with error message, you will be unable to understand what is wrong with your code. This is why it is so important to see every error message PHP emits. Every error message is not only a signal of a problem but also a description, what is certainly going wrong that will help you to fix a problem.

Again, for a learner, who can always ask a teacher to fix their code, or for just a passer by who don’t care for their code at all, it’s better to hide error messages. But for a programmer who do care for the code they write, a missed error message is a disaster. And a code that is hiding an error message is harmful.

2 Likes

You make some good points there, @colshrapnel. But I feel that it is also important for a beginner to learn early on to deal with the errors that their code produces, so they should always have their errors (even the notices) display as they are working on an application.

A beginner who always asks someone else to find their errors and help fix them will never learn to code properly. There is a lot to be gained in the learning process to be forced to independently figure out what is causing an error and how to fix it. And of course, if they have tried and then become stuck, they should ask a teacher or someone here on the forums.

1 Like

Again, I think your use of the term harmful, with the adjective “extremely” is a bit overzealous here.

Sure, claiming you could be hiding an error in your code is a fair statement, however, one should look at the source to determine, why this mistake is constantly happening.

Take the following examples at http://php.net/manual/en/mysqli-stmt.fetch.php

<?php
$mysqli = new mysqli("localhost", "my_user", "my_password", "world");

/* check connection */
if (mysqli_connect_errno()) {
    printf("Connect failed: %s\n", mysqli_connect_error());
    exit();
}

$query = "SELECT Name, CountryCode FROM City ORDER by ID DESC LIMIT 150,5";

if ($stmt = $mysqli->prepare($query)) {

    /* execute statement */
    $stmt->execute();

    /* bind result variables */
    $stmt->bind_result($name, $code);

    /* fetch values */
    while ($stmt->fetch()) {
        printf ("%s (%s)\n", $name, $code);
    }

    /* close statement */
    $stmt->close();
}

/* close connection */
$mysqli->close();
?>

Do you see what I see?

And lets look at prepare specifically
http://php.net/manual/en/mysqli.prepare.php

<?php
$mysqli = new mysqli("localhost", "my_user", "my_password", "world");

/* check connection */
if (mysqli_connect_errno()) {
    printf("Connect failed: %s\n", mysqli_connect_error());
    exit();
}

$city = "Amersfoort";

/* create a prepared statement */
if ($stmt = $mysqli->prepare("SELECT District FROM City WHERE Name=?")) {

    /* bind parameters for markers */
    $stmt->bind_param("s", $city);

    /* execute query */
    $stmt->execute();

    /* bind result variables */
    $stmt->bind_result($district);

    /* fetch value */
    $stmt->fetch();

    printf("%s is in district %s\n", $city, $district);

    /* close statement */
    $stmt->close();
}

/* close connection */
$mysqli->close();
?>

In both examples, they are throwing prepare into an IF statement. That brings about two possible outcomes now, either 1) the rule you have with IF statements hiding errors is being applied to liberally and to cases that isn’t true for, or 2) the documentation of PHP should be doing better to teach the user here, by removing the IF statement (for the record, I believe it is the latter).

However, the way PHP does this, really irks me and turns me away from using PHP for a lot of projects. I really dislike the fact that a class method can return two types. If successful, you get a statement object, if it fails, you get false. That just blows my mind, but I respect that is the direction PHP went (and I believe they sort of corrected this with PDO).

Anyway, back to the issue at hand. Sure you could be hiding an error (could be), but the issue isn’t specific people and their personal views on writing said piece of code, especially when the defacto-manual is suggesting the exact same thing in their examples. Take the argument/fight with the manual, get it fixed there, profit in that all those who then look there to see how something should be done, can find it done in friendlier, less prone to hiding errors, way.

3 Likes

Indeed, PHP manual is traditionally bad with code examples. Those you posted here are outdated, misleading, and shouldn’t be recommended to use in any environment.
I don’t see, however, why I can not/should not explain why this example is wrong and show the right way instead on a forum like this.

the way PHP does this, really irks me

Luckily, PHP itself is moving towards the right direction in the recent years, the way you should like it: a function either returns a correct value or throws an exception, so there is (technically) no more dual return types.

That would be great! (I may start to use it more, if they continue in that direction)

I’m not saying you shouldn’t, but maybe drop the overzealous nature of the responses? Again, my response was more to the adjectives used and the “over-hyping” of the situation. Surely there is a more tactful way of outlining the issue at hand?

I’m not saying coddle everyone, but rather, instead of claiming the house is on fire, claim that, there is a fire hazard, and given enough time, the following line could be problematic because it is hiding the ability for X to fail. And should it not fail, you may spend hours looking into a bug/help desk ticket that you could have avoided if you let the error show itself.

Just my 2 cents (or whatever it may be worth).

4 Likes

Thank you. Now I got it. English is not my native language and it is not the first time I am using inappropriate wording. So it should be less expressive.

But… honestly, if you ever spent several hours trying to debug a code with insufficient / turned off error reporting, you wouldn’t call any wording overzeslous.

3 Likes

For the record, your English is really good. I would not have guessed it wasn’t your native language, you at least write it extremely well.

I understand that immensely, been there, done that. Lots of overzealous and expletive words were shouted whilst doing it :wink:

3 Likes

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.