Guía defensiva
¿Cómo procesar registros incompletos con Python sin ocultar errores?
Los registros reales pueden tener campos ausentes, tipos inesperados o líneas truncadas. Un programa defensivo no debe convertir esos casos en datos confiables ni abandonar todo el lote sin explicar por qué.
Define el dato mínimo
Antes de procesar, identifica qué campos necesita la pregunta: hora, fuente y evento, por ejemplo. Una línea que no los contiene puede ser inválida para ese análisis aunque sea válida para otra finalidad. Escribe esa regla junto al procesamiento.
No rellenes campos críticos con valores inventados. Un valor por defecto puede ser adecuado para una etiqueta de presentación, pero no para una hora o identidad que cambiaría la interpretación de una señal.
Captura el fallo cerca de la entrada
Maneja errores de lectura o conversión por registro cuando el diseño de la tarea permita continuar. Conserva contador y motivo resumido para que el resultado indique cuántas líneas se excluyeron y por qué. No atrapes excepciones amplias para ocultar defectos del programa.
Ejemplo: un archivo de práctica contiene diez líneas y una no es JSON válido. El informe puede decir que nueve fueron analizadas y una quedó pendiente de formato. Eso es más honesto que reportar diez eventos o descartar el lote sin detalle.
Separa resultado y diagnóstico
La colección de eventos válidos responde a la pregunta analítica; el registro de errores explica sus límites. Guardarlos por separado permite contar y revisar ambos sin mezclar una advertencia con una observación de seguridad.
Cuando un error contiene texto original, evita reenviarlo sin revisión. Puede incluir datos personales o secretos. Conserva ubicación, tipo de error y referencia autorizada, no contenido sensible por defecto.
Detente cuando cambia la confianza
Continuar controladamente no significa que cualquier tasa de error sea aceptable. Define un umbral o revisión humana cuando faltan campos esenciales o la pérdida afecta una conclusión. La salida debe declarar que el análisis está incompleto.
Las pruebas cubren entrada válida, línea dañada y error de programa distinto. Así se demuestra que el tratamiento tolerante conserva el registro y no vuelve invisible un fallo de lógica.