Signalement des erreurs d'échappement en PHP avec @

Question

Je suis en train de remanier du code pour mon travail et je suis tombé sur des appels de fonctions préfixés par le symbole "@". Si j'ai bien compris, cela a pour but d'échapper au rapport d'erreur de PHP si l'appel échoue.

Ce genre de chose est-il une bonne pratique ? Je comprends le raisonnement dans un environnement de développement, mais lorsque le site est mis en production, toutes les erreurs ne devraient-elles pas être traitées correctement plutôt que d'être simplement échappées ?

L'utilisation de ce symbole signifierait donc que le développeur doit faire le tri dans le code à un stade ultérieur pour supprimer tous les échappatoires de signalement d'erreurs.

Je ne sais pas si je dois supprimer ces symboles et trouver un meilleur moyen de gérer les erreurs potentielles ou non.

Pour plus de clarté, la fonction utilisée était la fonction native PHP fsockopen() fonction.

Answer 1

C'est probablement l'une des pires pratiques que l'on puisse rencontrer dans un code php. Elle indique à l'interpréteur de supprimer les erreurs et d'essayer de faire tout ce que le code lui demande de faire, quel que soit le résultat.

Un bon moyen de vous entraîner, vous et vos coéquipiers, dans des chasses aux bugs fantômes qui durent toute la nuit, une fois que l'application s'est considérablement développée.

La méthode Try-catch avec traitement personnalisé des exceptions est la meilleure solution.

Answer 2

Je pense qu'il est parfois compréhensible d'utiliser @ pour appeler des fonctions comme fsockopen(), car lorsqu'elles échouent, elles génèrent un avertissement en plus de retourner false.

Dans certains cas, vous vous attendez à ce que ces appels échouent régulièrement et ne souhaitez donc pas qu'un avertissement soit émis. Il est évident que vous ne devriez pas afficher d'avertissements en production et que vous devriez plutôt les consigner dans un journal, mais vous pourriez tout de même utiliser l'opérateur @ pour éviter de remplir vos journaux. Vous pourriez empêcher les avertissements d'être signalés en modifiant le paramètre error_reporting, mais ce n'est pas idéal.

Answer 3

C'est ce qu'on appelle le opérateur de contrôle des erreurs et est généralement une chose très effrayante à envisager d'utiliser. Un avertissement du manuel (les caractères gras sont de moi) :

Actuellement, le préfixe d'opérateur de contrôle d'erreur "@". préfixe de l'opérateur va même désactiver rapport d'erreurs pour les erreurs critiques qui mettra fin à l'exécution du script. . Entre autres choses, cela signifie que si vous utilisez "@" pour supprimer les erreurs d'une certaine fonction et qu'elle n'est pas disponible ou a été mal saisie, le script va mourir sur place sans indication de la raison .

Answer 4

L'utilisation de l'opérateur "@" est très utile pour connaître que l'appel de la fonction peut échouer, comme, par exemple, la fonction fsockopen appeler. La meilleure pratique consiste à n'utiliser cette fonction que lorsque la fonction que vous appelez échoue souvent et qu'il s'agit d'un cas valable dans votre application. En outre, vous devez absolument vérifier la valeur de retour de la fonction après l'avoir appelée :

$fp = @fsockopen($hostname, $port);
if ($fp === false) {
    // handle connection failure
}
else {
    // handle connection success
}

Vous devez éviter deux choses :

1. Ne pas vérifier la valeur de retour ;
2. Utilisation de l'opérateur "@" lorsque vous ne vous attendez pas à une erreur, par exemple lors de l'ouverture d'un fichier local ou de l'envoi d'en-têtes. Lorsque l'ouverture d'un fichier local échoue, cela es une erreur et elle doit être traitée correctement.

Note : vous pouvez également consulter set_error_handler()

Answer 5

Si vous utilisez vos propres gestionnaires d'erreurs, l'opérateur @ ne vous aidera pas, vous obtiendrez toujours des événements d'erreur dans des situations où vous manipulez le "Warning" dans votre code ... comme ici fsockopen etc.

vous pouvez donc simplement supprimer efficacement l'avertissement de cette manière :

function renameWithOutExpectedAndSelfHandledErrors( ... ) {

  set_error_handler(function(){}); // deactivate all errors
  $result = rename('not existing','blafussel');
  restore_error_handler(); // restore old error-situation

  return $result;
}