mysql_affected_rows - update mysql php

PHP PDO en modo de excepción: ¿Aún necesita verificar el retorno de la función de ejecución(y otros)?

Question

TLDR: ¿Alguien sabe de casos específicos, además del que se muestra a continuación, donde PDO::exec() , PDO::query() , PDO::prepare() , o PDOStatement::execute() pueden devolver falso sin una excepción PDO::ATTR_ERRMODE , a pesar de que PDO::ATTR_ERRMODE se establece en PDO::ERRMODE_EXCEPTION ?

Estoy intentando decidir si deseo agregar un cheque para falso a cada consulta de base de datos que escribo en el futuro, o si eso es redundante.

Editar: actualmente uso MySQL exclusivamente, pero si la portabilidad es un factor, eso podría ser suficiente para basar la decisión. Yo uso PDO::ATTR_EMULATE_PREPARES => FALSE si eso importa.

Este es el caso específico que mencioné. Si prepara una declaración con 0 o más marcadores de posición (de cualquier tipo) y luego proporciona una matriz de argumentos a PDOStatement::execute() con más elementos que marcadores de posición, se devuelve false sin que se PDOStatement::execute() una excepción. Tenga en cuenta que la ejecución tiene éxito (y solo el enlace adicional falla) si se PDOStatement::bindValue() su lugar. El uso de menos parámetros que los marcadores de posición arroja una excepción, ya sea que los parámetros se hayan suministrado a la función de ejecución a través de una matriz o enlazados usando PDOStatement::bindValue() / PDOStatement::bindParam() .

// Execute returns false, no exception thrown
$so = $rh->pdo->prepare("SELECT * FROM config");
if($so->execute([''Test'']) === FALSE) echo ''1. False returned <br />'';   

// Execute does not return false, no exception thrown
$so = $rh->pdo->prepare("SELECT * FROM config");
if($so->bindValue(1, ''Test'') === FALSE) echo ''2. Binding failed <br />'';
if($so->execute() === FALSE) echo ''2. False not returned <br />'';   

// Execute returns false, no exception thrown
$so = $rh->pdo->prepare("SELECT * FROM config WHERE webmaster_name = ?");
if($so->execute([''Test'', ''Wee'']) === FALSE) echo ''3. False returned <br />'';    

// Execute does not return false, no exception thrown
$so = $rh->pdo->prepare("SELECT * FROM config WHERE webmaster_name = ?");
$so->bindValue(1, ''Test'');
if($so->bindValue(2, ''Wee'') === FALSE) echo ''4. Binding failed <br />'';
if($so->execute() === FALSE) echo ''4. False not returned <br />'';   

Outputs:
1. False returned
2. Binding failed
3. False returned
4. Binding failed

En una instrucción select, no es particularmente peligroso en este caso confiar en excepciones, ya que un error ocurriría de todos modos si intentara llamar a un método fetch en FALSE lugar de un objeto PDOStatement . Pero hay consultas como INSERTAS o ACTUALIZACIONES que pueden fallarle silenciosamente si no realiza el control falso.

He estado aprendiendo PDO y estoy tratando de decidir sobre prácticas generales para el manejo de errores en el futuro.

Definitivamente prefiero las excepciones, ya que tengo un buen controlador de sitio amplio que se puede configurar para diferentes escenarios. Y parece que el uso de excepciones significará menos tipeo, ya que no tiene que verificar los retornos de muchas funciones de PDO explícitamente.

¿O USTED? (cue música dramática)

Cuando estaba leyendo, me encontré con más de una mención de las funciones de PDO (no la variedad de búsqueda) que devuelve falso sin que se produzca una excepción.

Mi pregunta es si considera o no que es una buena práctica verificar también el retorno de esas funciones, o si la mayoría de las personas considera que es excesivo.

He visto muchas declaraciones contradictorias en SO. He visto numerosas declaraciones por un lado: "Las excepciones PDO son confiables"; "Las excepciones PDO siempre se arrojarán cuando FALSO se haya devuelto" (upvoted por personas que dicen "Creo que es cierto").

Estos son algunos comentarios que me llevan a preguntarme, aunque todavía tengo que ver un ejemplo específico además del que mencioné.

De ¿Pueden los métodos de PDO fallar y no arrojar PDOException? :

Parece que no puedo replicar este escenario de algunos casos de prueba (tengo el modo de emulación desactivado).

1. "(Ryan Vincent) cuando emula es falso y ... los tipos de enlace son incorrectos. A veces no arroja una excepción".

¿Este parece haber sido refutado? No estoy seguro de cómo probar esto.

2. "(Xorifelse) Ahora, para comprometernos a fallar, creo que hay 1 escenario que haría que se devuelva false sin lanzar una excepción y es cuando la conexión al servidor cae después de conectarse a la base de datos y antes de llamar a PDO::commit , Es muy bueno saber si tienes un servidor de base de datos remoto. Para responder a tu pregunta, sí, puede fallar sin lanzar una excepción, pero su tiempo tiene que ser muy específico, incluso más si tienes una base de datos local ".

¿Desde un falso PDO devuelto ejecutar () lo mismo que la excepción que arrojó? :

Este es el único escenario específico que he encontrado que he podido duplicar (ver arriba).

3. "(Niksac) He visto execute() devolviendo false sin lanzar una excepción que es una especie de comportamiento inesperado / malo en mi opinión. Esto significa que básicamente tenemos que hacer ambas cosas: manejo de errores y excepciones en paralelo. En mi caso: si Preparé una consulta de inserción sin ningún parámetro y luego la ejecuté con un parámetro. Execute no lanzará una excepción sino que devolverá false .

De debería verificar el valor de retorno de una operación de ejecución en pdo php :

4. "(castis) $stmt->execute() puede devolver absolutamente false sin lanzar una excepción".

Creo que encontré al menos otra mención no específica de que es posible (falso devuelto, sin excepción), aunque no puedo rastrearlos de nuevo.

Mirando a través de los tutoriales de PDO en línea, la mayoría de ellos no verifican los retornos cuando se usa el modo de excepción. Pero sí encontré a un par de personas recomendándolo.

El caso que describí no es algo que pueda estropear en el uso diario. O si lo arruino, debería averiguarlo de inmediato. Y si alguna vez construí dinámicamente el número de marcadores de posición o parámetros en la consulta, sabría asegurarme de que el recuento coincida y / o verifique si es falso en este caso.

Simplemente no quiero comprobar el retorno de cada uso de ejecutar, consultar, etc., si no es realmente necesario. Si el ejemplo que mencioné es el único caso conocido, me sentiría cómodo dejando la comprobación falsa en la mayoría de las consultas, lo que me permitiría hacer más encadenamiento de métodos:

$user_info = $rh->pdo->query("SELECT * FROM users WHERE user_id = 1")->fetch();

// vs

$so = $rh->pdo->query("SELECT * FROM users WHERE user_id = 1");
if($so === FALSE) // Throw an exception
$user_info = $so->fetch();

Supongo que lo que estoy buscando es una confirmación por parte de los desarrolladores más experimentados de que está bien omitir este control ya que veo que la gente lo hace. O eso, o personas que me dicen cómo se han quemado al eludir ese control.

Answer 1

Definitivamente hay diferentes errores dependiendo de la base de datos que estés usando. Si la portabilidad es una preocupación, no confiaría en algo de lo que podría ser la idiosincrasia de MySQL que pareces encontrar arriba.

Por ejemplo, hay estos:

• PHP PDO Postgres versus tipo de columna Sqlite para el recuento (*)
• El controlador PHP Postgres PDO no es compatible con la instrucción preparada?