tag - ¿Está bien suprimir/ocultar los avisos de PHP?

strip_tags()

Question

He suprimido los avisos durante bastante tiempo sin ningún problema, pero estoy empezando a preguntarme si estoy haciendo lo correcto. Parece que no puedo encontrar una razón lógica por la que no debería simplemente suprimirlos, sino que otras personas parecen pensar que suprimirlos usando el informe de errores es algo horrible de hacer, pero ¿por qué?

Lo más cercano a una respuesta que pude encontrar fue en esta pregunta, pero aún está lejos de la respuesta que estoy buscando. ¿Hay algún tipo de inconveniente imprevisto para ocultar todos los avisos que genera PHP? Por ejemplo, para incluir una variable de una llamada POST nuevamente en el formulario porque hubo errores, simplemente usaría:

<?= $_POST[''variable''] ?>

Esto generaría un aviso de PHP. Para arreglar ese aviso, podría usar algo como esto:

<?= isset($_POST[''variable'']) ? $_POST[''variable''] : '''' ?>

Pero, ¿es esto realmente necesario? ¿Se beneficiará realmente mi código de hacer esto en lugar de simplemente hacer eco de la variable si existe o no y potencialmente crear un aviso de PHP? Me parece que ser capaz de ignorar los avisos es un beneficio de usar PHP, ya que entonces no tiene que preocuparse de si una variable está definida o no, especialmente para un ejemplo como este donde no parece importar.

También aprovecho la capacidad de PHP para cambiar automáticamente el tipo / lanzamiento de una variable dependiendo de cómo se esté utilizando y, a menudo, encontrará fragmentos de código como este:

for ($i = 0; $i < $limit; $i++) $results[] = $i; // Example

donde $results no se ha definido previamente, pero se convierte en una matriz cuando intento agregarle un nuevo elemento como una matriz. Prefiero hacerlo de esta manera porque si no se agregan resultados a la matriz y necesito almacenar esa información o convertirla a JSON por alguna razón, entonces esa variable en particular no se definirá y, por lo tanto, se ahorrará ancho de banda adicional, incluso si es minuto.

$data = stdClass; // For reference, in my case this would be defined before this code
$data->results = array();
$limit = 0;
for ($i = 0; $i < $limit; $i++) $data->results[] = $i;
print json_encode($data);
// {"results":[]}

versus

$data = stdClass; // For reference
$limit = 0;
for ($i = 0; $i < $limit; $i++) $data->results[] = $i;
print json_encode($data);
// []

La pregunta nuevamente: ¿qué beneficio real, si es que lo hay, obtengo al corregir errores de notificación en lugar de simplemente suprimirlos? ¿Cómo puede / podría dañar mi código?

Answer 1

Desde mi punto de vista, nunca debe suprimir los errores, ningún tipo de ellos, avisos o no. Puede que le brinde alguna comodidad ahora, pero en el futuro, enfrentará muchos, muchos problemas con su código cuando lo mantenga.

Supongamos que tiene una variable que desea mostrar como el primer ejemplo anterior. Sí, usar isset es un poco complicado, pero tal vez su aplicación debería manejar el caso vacío especial de todos modos, mejorando así la experiencia. Ejemplo:

if (isset($var)) {
echo $var;
} else {
echo "Nothing is found. Try again later.";
}

Si solo tuvieras echo $var; y si esta era una vista pública que un usuario estaba leyendo, simplemente no verían nada allí, lo que podría causar confusión. Por supuesto, este es solo un caso especial en el que corregir los avisos de PHP puede mejorar su aplicación.

No debe tomarse como un problema o inconveniente cuando cuida las notificaciones en el código PHP, ya que se supone que el código está limpio. Prefiero tener un código libre de avisos que ver código limpio cuando lo abro en la fuente. Por supuesto, ambos es definitivamente mejor! :)

Nuevamente, los errores (incluso si no son fatales) causarán problemas en el futuro. Si ya estás haciendo cosas como echo $var; sin comprobarlo, es una suposición de que existe una variable, incluso si sabe que podría no hacerlo, simplemente le dará el hábito de asumir que las cosas existen y funcionan . Esto puede ser pequeño ahora, pero después de un tiempo descubrirá que se causará muchos, muchos problemas.

Los avisos están ahí por una razón. Si todos hicimos error_reporting(E_ALL ^ E_NOTICE) en nuestro código, simplemente somos irresponsables por nuestro código. Si eres capaz de solucionarlo, ¿por qué estás siendo perezoso y no lo estás haciendo? Claro, envíe 1.0 con avisos, corríjalos más tarde, eso es lo que todos decimos. Pero es mejor hacerlo como un hábito, código perfecto la primera vez. Si pasa 15 minutos escribiendo el código plagado de avisos, y luego pasa 2 horas en un tiempo de desarrollo posterior para corregirlos , ¿por qué no dedicar una hora y media a perfeccionar el código al escribirlo en primer lugar?

Escribir un buen código debe ser un hábito, no un inconveniente. Los mensajes de error están ahí por una razón. Respétalos, repáralos, y ahí tienes, eres un programador responsable.

También allana un camino para los futuros mantenedores de su código.

Answer 2

En mi experiencia, los avisos generalmente indican una buena probabilidad de que haya un error en algún lugar de su código, generalmente del caso en el que espera que se establezca una determinada variable en un determinado punto, pero habrá casos en los que no lo esté, y usted Empezaré a preguntarme por qué parte de tu página no aparece o comienza a fallar aleatoriamente.

Por supuesto, las computadoras no son tan inteligentes, y habrá casos en que el código sea lo suficientemente claro y no le importe si hay alguna advertencia, pero para eso está el operador @ .

Answer 3

Respetuosamente, no estoy de acuerdo con algunos de los comentarios que sugieren que nunca debe suprimir los avisos. Si sabe lo que está haciendo, creo que usar @ es muy útil, especialmente para manejar variables no definidas o elementos de matriz. No me malinterpretes: estoy de acuerdo en que, en manos de un programador inexperto o descuidado, @ puede ser malo. Sin embargo, considere este ejemplo:

public function foo ($array) {
if (isset ($array[0])) {
$bar = $array[0];
} else {
$bar = null;
}
// do something with $bar
}

es funcionalmente idéntico a

public function foo ($array) {
$bar = @$array[0];
// do something with $bar
}

pero es IMHO menos legible y más trabajo para escribir. En este tipo de casos, sé que hay exactamente dos posibilidades: una variable está configurada o no. No sé de antemano, pero debo proceder en ambos casos. No veo nada de malo en usar @ en ese caso. Si, tambien podrias escribir

public function foo ($array) {
$bar = isset ($array[0]) ? $array[0] : null;
// do something with $bar
}

pero me parece que sólo un poco mejor. Para mí, la legibilidad y la brevedad del código son valores en sí mismos, y el hecho de que el código se hinche con pruebas de prueba es una tontería.

Por supuesto, si no me equivoco, usar @ toma un poco más de tiempo para ejecutar esa prueba, pero seamos honestos: ¿qué parte de nuestro código es realmente crítica para el rendimiento? En un bucle que se ejecuta mil millones de veces, probablemente usaría isset en su lugar, pero en la mayoría de los casos, no hace ninguna diferencia para el usuario.

Answer 4

Supongamos que tiene un aviso que no debe ignorar. Este aviso se ocultará en todos los avisos que normalmente ignora.

En mi humilde opinión, las advertencias no deben ser ignoradas. Siempre debes tener cuidado de las advertencias para evitar errores. Cada vez que tengo un aviso en mi archivo de registro, lo trato como un error.

Además, si muchos usuarios acceden a su sitio, obtendrá un archivo de registro muy grande.