Porque es terriblemente inespecífico y no le permite hacer nada interesante con la excepción. Además, si está atrapando cada excepción, podría haber muchas excepciones que ni siquiera sabe que están sucediendo (lo que podría hacer que su aplicación falle sin que usted realmente sepa por qué). Debería poder predecir (mediante la lectura de documentación o la experimentación) específicamente qué excepciones debe manejar y cómo manejarlas, pero si las suprime ciegamente desde el principio, nunca lo sabrá.
Por petición popular, he aquí un ejemplo. Un programador está escribiendo el código de Python y ella obtiene un IOError
. En lugar de investigar más a fondo, decide capturar todas las excepciones:
def foo():
try:
f = open("file.txt")
lines = f.readlines()
return lines[0]
except:
return None
no se da cuenta del problema en sus caminos: ¿y si el archivo existe y es accesible, pero está vacío? Entonces este código levantará un IndexError
(ya que la lista lines
está vacía). Así que pasará horas preguntándose por qué está recibiendo None
de esta función cuando el archivo existe y no está bloqueado sin darse cuenta de algo que sería obvio si ella hubiera sido más específica en la captura de errores, que es que está accediendo a datos que podrían no existe.
Tengo que coger 'em todo – jamylak
supongo que es mejor para atrapar todo en un código de producción, pero a medida que se desarrolla el software, se puede hacer que su código sea difícil para la depuración .... –
@jamylak: http: //stephenvick.wordpress.com/2010/08/02/pokemon-exception-handling/ –