¿Error al verificar overkill?

Question

¿Qué comprobación de errores haces? ¿Qué comprobación de errores es realmente necesaria? ¿Realmente necesitamos verificar si un archivo se ha guardado con éxito? ¿No debería funcionar siempre si se prueba y funciona bien desde el primer día?

Me encuentro a mí mismo comprobando errores para cada pequeña cosa, y la mayoría de las veces si se siente excesivo. Cosas como verificar si un archivo se ha escrito correctamente en un sistema de archivos, verificar si una declaración de base de datos falló ....... ¿no deberían ser cosas que funcionan o no?

¿Cuánta comprobación de errores hace usted? ¿Hay elementos de comprobación de errores que dejas de lado porque confías en que funcionarán?

Estoy seguro de que recuerdo haber leído en algún lugar algo parecido a "no pruebes las cosas que nunca sucederán realmente" ... pero no recuerdo la fuente.

Entonces, ¿debería verificarse si falla todo lo que podría fallar? ¿O deberíamos simplemente confiar en esas operaciones más simples? Por ejemplo, si podemos abrir un archivo, ¿deberíamos verificar si la lectura de cada línea falla o no? Tal vez depende del contexto dentro de la aplicación o la aplicación en sí.

Sería interesante escuchar lo que otros hacen.

ACTUALIZACIÓN: Como un ejemplo rápido. Guardo un objeto que representa una imagen en una galería. Luego guardo la imagen en el disco. Si falla el guardado del archivo tendré que mostrar la imagen aunque el objeto crea que hay una imagen. Podría verificar si falla la imagen que se guarda en el disco y luego eliminar el objeto o, alternativamente, envolver la imagen guardada en una transacción (unidad de trabajo), pero eso puede ser costoso cuando se usa un motor db que usa bloqueo de tabla.

Gracias,

James.

Answer 1

En general, sigo estas reglas.

1. Valide excesivamente la entrada del usuario.
2. Validar API públicas.
3. Utilice los asertos que se compilan del código de producción para todo lo demás.

Answer 2

Si se queda sin espacio libre e intenta escribir un archivo y no verifica los errores, su aplicación caerá silenciosamente o con mensajes estúpidos. Odio cuando veo esto en otras aplicaciones.

Answer 3

yo no estoy dirigiendo a toda la pregunta, sólo esta parte:

lo tanto debe todo lo que podría posiblemente fallan ser comprobado por el fracaso? ¿O deberíamos simplemente confiar en las operaciones más simples de ?

Me parece que la comprobación de errores es más importante cuando el paso NEXT importa. Si la falla al abrir un archivo permitirá que los mensajes de error se pierdan permanentemente, entonces eso es un problema. Si la aplicación simplemente muere y le da un error al usuario, entonces consideraría un tipo diferente de problema. Pero morir silenciosamente, o colgar silenciosamente, es un problema que debes hacer lo mejor que puedas para codificar.Entonces, si algo es una "operación simple" o no es irrelevante para mí; depende de lo que suceda a continuación, o cuál sería el resultado si fallara.

Answer 4

En cuanto a su ejemplo ...

puedo guardar un objeto que representa una imagen en una galería. Luego guardo la imagen en el disco. Si falla el guardado del archivo, tendré [no] una imagen que mostrar aunque el objeto crea que hay una imagen. Podría verificar si falla la imagen que se guarda en el disco y luego eliminar el objeto o, alternativamente, envolver la imagen guardada en una transacción (unidad de trabajo), pero eso puede ser costoso cuando se usa un motor db que usa bloqueo de tabla.

En este caso, recomendaría guardar la imagen en el disco primero antes de guardar el objeto. De esta forma, si la imagen no se puede guardar, no tiene que intentar deshacer la galería. En general, las dependencias deben escribirse primero en el disco (o ponerlas en una base de datos).

En cuanto a la comprobación de errores ... busque errores que tengan sentido. Si fopen() le da una identificación de archivo y no obtiene un error, generalmente no necesita verificar fclose() en esa ID de archivo devolviendo "ID de archivo inválido". Sin embargo, si la apertura y el cierre del archivo son tareas disjuntas, podría ser una buena idea verificar ese error.

Answer 5

Puede que esta no sea la respuesta que está buscando, pero solo hay una respuesta "correcta" cuando se analiza en el contexto completo de lo que está tratando de hacer.

Si está escribiendo un prototipo para uso interno y si obtiene un error extraño, no importa, entonces está perdiendo tiempo y dinero de la compañía al agregar la verificación adicional.

Por otro lado, si está escribiendo software de producción para el control del tráfico aéreo, entonces el tiempo adicional para manejar todos los errores concebibles puede ser bien gastado.

Lo veo como una compensación: el tiempo extra empleado en escribir el código de error frente a los beneficios de haber manejado ese error en el momento en que ocurre. Tratar religiosamente cada error no es necesario IMO óptimo.