2010-01-25 23 views
6

Consultas de ejemplo en algunos tutoriales siempre terminan con:¿Debería finalizar siempre las consultas de mysql con "o morir?"

or die(mysql_error()); 

puedo ver por qué se haría veces que desee hacer esto, sino que incluso lo uso para consultas que realmente no debería causar un problema. ¿Es una buena práctica usar esto siempre o solo lo hacen para ayudarlo a depurar a medida que aprende?

Respuesta

0

La palabra "no debería" está mal aquí. Las consultas que no deberían tener un problema aún pueden verse afectadas por factores externos, p. conexión a la base de datos bajando.

0

sino que incluso lo uso para consultas que realmente no debería causar un problema

Incluso el más simple SELECT * FROM FOO puede causar un problema si la red entre el servidor web y el servidor de base de datos se cae. Es una buena práctica, porque cuando se trata de sistemas externos como bases de datos, realmente no se puede asumir que algo es 'seguro'.

En el código de producción, es posible que no desee utilizar die() para manejar los errores; tal vez podría ejecutar algún código personalizado para manejarlo. En cualquier caso, definitivamente debe manejar el error de una manera u otra, y die() es una buena manera de comenzar.

1

Depende de lo que quiere decir "no debería ser un problema".

Si quiere decir "bueno, no fallará", ¿qué ocurre si el servidor de la base de datos se desconecta?

Solo si quiere decir "No importa si falla o no, la secuencia de comandos puede seguir ejecutándose sin problemas", debería considerar no tener allí el or die.

0

Usted no necesita un

or die() 

Pero debe tener algún tipo de sistema de gestión de errores. Si todavía no tienes uno, lo agregaría a mis consultas, incluso las simples.

EDITAR: Para aclarar, por "eso" me refiero a la declaración o die().

13

NO.

¡Evite que a toda costa!

  1. es un mensaje terrible para mostrar un usuario final
  2. mysql_error puede exponer información que no desea ser dado
  3. No hay manera de manejar el error, es decir volver.

Imagínese una base de datos de transacciones - su cliente envía el dinero, así que hay que modificar dos tablas (dos consultas).

Primero uno transfiere dinero de X a Y y lo logra. El segundo tiene que restar Y de X falla.

No tiene forma de revertir la transacción y no se registra el error. Efectivamente, el usuario Y está contento y X dejó confundir dónde se fue el dinero ...

Utilice un manejo de errores razonable para las consultas, ya sea que realice una clase que se encargará de eso o use ORM.

+0

completamente de acuerdo: el uso de 'o morir()' debe eliminarse de los manuales y libros, y se debe mostrar el manejo correcto de errores (incluso si no se trata de un elemento básico). – HorusKol

+0

Bien, por favor, por favor, eduquen al OP novato y a este comentarista novato sobre a dónde recurrir para un manejo de errores PHP sólido como una roca que sea independiente del marco. – Drew

+0

@ Andrew, Usar un marco es un buen comienzo: una vez que se sienta cómodo con el marco, puede echar un vistazo a sus fuentes y ver cómo manejan los errores. – LiraNuna

0

Pensaba que no estaría mal usarlo en la parte superior de las páginas donde quiera que esté la información de conexión de la base de datos. Úselo cuando intente conectarse solo a la base de datos.

Pero, ¿por qué usarlo en cada consulta que realice? Obviamente, si estuviera conectado a la base de datos, entonces, si lo conoce, ¡no deberían producirse otros errores, entonces no vería por qué no podría evitar usarlo más de una vez por página!

Cuestiones relacionadas