El principal problema aquí es que ignora todo y cualquier error: Falta de memoria, la CPU se está quemando, el usuario quiere detenerse, el programa quiere salir, Jabberwocky está matando usuarios.

Esto es demasiado. En tu cabeza, estás pensando "Quiero ignorar este error de red". Si algo inesperado sale mal, entonces su código continúa silenciosamente y se rompe de maneras completamente impredecibles que nadie puede depurar.

Es por eso que debe limitarse a ignorar específicamente solo algunos errores y dejar pasar el resto.

Ejecutar tu pseudo código literalmente ni siquiera da ningún error:

try:
    something
except:
    pass

Como si fuera un código perfectamente válido, en lugar de lanzar un NameError. Espero que esto no sea lo que quieres.

¿Por qué es "excepto: pasar" una mala práctica de programación?

¿Por qué es esto malo?

try:
    something
except:
    pass

Esto incluye todas las excepciones posibles, incluyendo GeneratorExit, KeyboardInterrupt, y SystemExit - que son excepciones que probablemente no tiene la intención de atrapar. Es lo mismo que atrapar BaseException.

try:
    something
except BaseException:
    pass

Las versiones anteriores de de la documentación de dicen :

Dado que cada error en Python genera una excepción, usar except: puede producir muchos errores de programación parecen problemas de tiempo de ejecución, lo que dificulta el proceso de depuración.

Jerarquía de Excepciones de Python

Si captura una clase de excepción padre, también captura todas sus clases hijas. Es mucho más elegante para atrapar solo las excepciones que está preparado para manejar.

Aquí está la jerarquía de excepciones de Python 3 - ¿realmente quieres atraparlos a todos?:

BaseException
 +-- SystemExit
 +-- KeyboardInterrupt
 +-- GeneratorExit
 +-- Exception
      +-- StopIteration
      +-- StopAsyncIteration
      +-- ArithmeticError
      |    +-- FloatingPointError
      |    +-- OverflowError
      |    +-- ZeroDivisionError
      +-- AssertionError
      +-- AttributeError
      +-- BufferError
      +-- EOFError
      +-- ImportError
           +-- ModuleNotFoundError
      +-- LookupError
      |    +-- IndexError
      |    +-- KeyError
      +-- MemoryError
      +-- NameError
      |    +-- UnboundLocalError
      +-- OSError
      |    +-- BlockingIOError
      |    +-- ChildProcessError
      |    +-- ConnectionError
      |    |    +-- BrokenPipeError
      |    |    +-- ConnectionAbortedError
      |    |    +-- ConnectionRefusedError
      |    |    +-- ConnectionResetError
      |    +-- FileExistsError
      |    +-- FileNotFoundError
      |    +-- InterruptedError
      |    +-- IsADirectoryError
      |    +-- NotADirectoryError
      |    +-- PermissionError
      |    +-- ProcessLookupError
      |    +-- TimeoutError
      +-- ReferenceError
      +-- RuntimeError
      |    +-- NotImplementedError
      |    +-- RecursionError
      +-- SyntaxError
      |    +-- IndentationError
      |         +-- TabError
      +-- SystemError
      +-- TypeError
      +-- ValueError
      |    +-- UnicodeError
      |         +-- UnicodeDecodeError
      |         +-- UnicodeEncodeError
      |         +-- UnicodeTranslateError
      +-- Warning
           +-- DeprecationWarning
           +-- PendingDeprecationWarning
           +-- RuntimeWarning
           +-- SyntaxWarning
           +-- UserWarning
           +-- FutureWarning
           +-- ImportWarning
           +-- UnicodeWarning
           +-- BytesWarning
           +-- ResourceWarning

No Hagas esto

Si está utilizando esta forma de excepción manipulación:

try:
    something
except: # don't just do a bare except!
    pass

Entonces no podrá interrumpir su bloque something con Ctrl-C. Su programa pasará por alto todas las posibles excepciones dentro del bloque de código try.

Aquí hay otro ejemplo que tendrá el mismo comportamiento indeseable: {[18]]}

except BaseException as e: # don't do this either - same as bare!
    logging.info(e)

En su lugar, intente capturar solo la excepción específica que sabe que está buscando. Por ejemplo, si sabe que puede obtener un valor-error en una conversión:

try:
    foo = operation_that_includes_int(foo)
except ValueError as e:
    if fatal_condition(): # You can raise the exception if it's bad,
        logging.info(e)   # but if it's fatal every time,
        raise             # you probably should just not catch it.
    else:                 # Only catch exceptions you are prepared to handle.
        foo = 0           # Here we simply assign foo to 0 and continue. 

Otra explicación con otro ejemplo

Es posible que lo esté haciendo porque ha estado raspando web y ha estado obteniendo, por ejemplo, un UnicodeError, pero debido a que ha utilizado la captura de excepciones más amplia, su código, que puede tener otros defectos fundamentales, intentará ejecutarse hasta completarse, desperdiciando ancho de banda, tiempo de procesamiento, desgaste de su equipo, se quedará sin memoria, recopilando datos basura, etc.

Si otras personas te están pidiendo que completes para que puedan confiar en tu código, entiendo que te sientas obligado para manejar todo. Pero si está dispuesto a fallar ruidosamente a medida que se desarrolla, tendrá la oportunidad de corregir problemas que solo pueden aparecer intermitentemente, pero que serían errores costosos a largo plazo.

Con un manejo de errores más preciso, el código puede ser más robusto.

>>> import this

El Zen de Python, por Tim Peters

Lo bello es mejor que lo feo.
Lo explícito es mejor que lo implícito.
Simple es mejor que complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Disperso es mejor que denso.
La legibilidad cuenta.
Los casos especiales no son lo suficientemente especiales como para romper las reglas.
Aunque la practicidad vence a la pureza.
Los errores nunca deben pasar en silencio.
Excepto explícitamente silenciado.
Frente a la ambigüedad, rechaza la tentación de adivinar.
Debería haber una obvious y preferiblemente sólo una obvious forma obvia de hacerlo.
Aunque esa forma puede no ser obvia al principio a menos que seas holandés.
Ahora es mejor que nunca.
Aunque nunca es a menudo mejor que bien ahora.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es fácil de explicar, puede ser una buena idea.
Los espacios de nombres son una gran idea hon vamos a hacer más de esos!

Así que, aquí está mi opinión. Cada vez que encuentre un error, debe hacer algo para manejarlo, es decir, escribirlo en el archivo de registro u otra cosa. Al menos, te informa que solía haber un error.

Debe usar al menos except Exception: para evitar capturar excepciones del sistema como SystemExit o KeyboardInterrupt. Aquí está enlace a los documentos.

En general, debe definir explícitamente las excepciones que desea capturar, para evitar la captura de excepciones no deseadas. Deberías saber qué excepciones ignoras .

Primero, viola dos principios del Zen de Python :

• Lo explícito es mejor que lo implícito
• Los errores nunca deben pasar en silencio

Lo que significa, es que intencionalmente haces que tu error pase silenciosamente. Además, no sabe qué error ocurrió exactamente, porque except: pass atrapará cualquier excepción.

En segundo lugar, si tratamos de abstraernos del Zen de Pitón, y hablar en términos de cordura justa, usted debe sepa que usar except:passle deja sin conocimiento y control en su sistema. La regla general es plantear una excepción, si ocurre un error, y tomar las acciones apropiadas. Si no sabe de antemano qué acciones deberían ser, al menos registre el error en algún lugar (y mejor vuelva a plantear la excepción):

try:
    something
except:
    logger.exception('Something happened')

Pero, por lo general, si intentas atrapar alguna excepción, ¡probablemente estás haciendo algo mal!

La construcción except:pass esencialmente silencia todas y cada una de las condiciones excepcionales que surgen mientras se ejecuta el código cubierto en el bloque try:.

Lo que hace que esta mala práctica es que por lo general no es lo que realmente quieres. Más a menudo, surge alguna condición específica que desea silenciar, y except:pass es demasiado un instrumento contundente. Hará el trabajo, pero también enmascarará otras condiciones de error que probablemente no haya anticipado, pero puede muy bien quiero tratar de otra manera.

Lo que hace que esto sea particularmente importante en Python es que por los modismos de este lenguaje, las excepciones no son necesariamente errores. A menudo se usan de esta manera, por supuesto, al igual que en la mayoría de los idiomas. Pero Python en particular los ha usado ocasionalmente para implementar una ruta de salida alternativa de algunas tareas de código que no es realmente parte del caso de ejecución normal, pero que aún se sabe que aparece de vez en cuando e incluso se puede esperar en la mayoría de los casos caso. SystemExit ya ha sido mencionado como un ejemplo antiguo, pero el ejemplo más común hoy en día puede ser StopIteration. El uso de excepciones de esta manera causó mucha controversia, especialmente cuando los iteradores y generadores se introdujeron por primera vez en Python, pero finalmente la idea prevaleció.

La razón #1 ya ha sido indicada - oculta errores que no esperabas.

(#2) - Hace que su código sea difícil de leer y entender para otros. Si detecta una excepción FileNotFoundException cuando está tratando de leer un archivo, entonces es bastante obvio para otro desarrollador qué funcionalidad debería tener el bloque 'catch'. Si no especifica una excepción, entonces necesita comentarios adicionales para explicar lo que debe hacer el bloque.

(#3) - demuestra programación perezosa. Si usa el genérico try/catch, indica que no comprende los posibles errores de tiempo de ejecución en su programa, o que no sabe qué excepciones son posibles en Python. Detectar un error específico muestra que comprende tanto el programa como el rango de errores que arroja Python. Es más probable que esto haga que otros desarrolladores y revisores de código confíen en su trabajo.

Entonces, ¿qué salida produce este código?

fruits = [ 'apple', 'pear', 'carrot', 'banana' ]

found = False
try:
     for i in range(len(fruit)):
         if fruits[i] == 'apple':
             found = true
except:
     pass

if found:
    print "Found an apple"
else:
    print "No apples in list"

Ahora imagine la try-except block es cientos de líneas de llamadas a una jerarquía de objetos compleja, y se llama en medio del árbol de llamadas de un programa grande. Cuando el programa sale mal, ¿dónde empiezas a buscar?

En general, puede clasificar cualquier error / excepción en una de tres categorías :

• Fatal : No es tu culpa, no puedes prevenirlos, no puedes recuperarte de ellos. Ciertamente no debe ignorarlos y continuar, y dejar su programa en un estado desconocido. Simplemente deje que el error termine su programa, no hay nada que pueda hacer.

• Boneheaded : Su propia culpa, muy probablemente debido a un descuido, error o error de programación. Usted debería arreglar el error. Una vez más, ciertamente no debe ignorar y continuar.

• Exógeno : Puede esperar estos errores en situaciones excepcionales, como archivo no encontrado o conexión terminada. Debe manejar explícitamente estos errores, y solo estos.

En todos los casos except: pass solo dejará su programa en un estado desconocido, donde puede causar más daño.

En pocas palabras, si se lanza una excepción o error, algo está mal. Puede que no sea algo muy malo, pero crear, lanzar y detectar errores y excepciones solo por el bien de usar declaraciones goto no es una buena idea, y rara vez se hace. el 99% de las veces, había un problema en alguna parte.

Hay que tratar los problemas. Al igual que en la vida, en la programación, si dejas los problemas en paz y tratas de ignorarlos, no se van por su cuenta un montón de tiempos; en cambio se hacen más grandes y se multiplican. Para evitar que un problema crezca en usted y golpee de nuevo más adelante en el camino, ya sea 1) eliminarlo y limpiar el desorden después, o 2) contenerlo y limpiar el desorden después.

Simplemente ignorar excepciones y errores y dejarlos así es una buena manera de experimentar fugas de memoria, conexiones de base de datos sobresalientes, bloqueos innecesarios en los permisos de archivos, etc.

En raras ocasiones, el problema es tan minúsculo, trivial, y-aparte de necesitar una oportunidad...catch block - autónomo, que realmente no hay ningún lío que limpiar después. Estas son las únicas ocasiones en las que esta mejor práctica no necesariamente se aplica. En mi experiencia, esto ha significado generalmente que lo que sea que el código está haciendo es básicamente mezquino y renunciable, y algo como intentos de reintento o mensajes especiales no vale la pena ni la complejidad ni sostener el hilo.

En mi empresa, la regla es casi siempre haz algo en un bloque catch, y si no haces nada, siempre debes colocar un comentario con una muy buena razón para no hacerlo. Nunca debe pasar o dejar un bloque de captura vacío cuando hay algo que hacer.

En mi opinión los errores tienen una razón para aparecer, que mi sonido estúpido, pero esa es la forma en que es. Una buena programación solo genera errores cuando tienes que manejarlos. Además, como leí hace algún tiempo, "la Sentencia pass es una Sentencia que muestra que el código se insertará más tarde", por lo que si desea tener una sentencia except-vacía, siéntase libre de hacerlo, pero para un buen programa habrá una parte que falta. porque no manejas las cosas que deberías tener. Las excepciones que aparecen le dan la oportunidad de corregir datos de entrada o para cambiar su estructura de datos para que estas excepciones no vuelvan a ocurrir (pero en la mayoría de los casos (Network-exceptions, General input-exceptions) excepciones indican que las siguientes partes del programa no se ejecutarán bien. Por ejemplo, una excepción de red puede indicar una conexión de red rota y el programa no puede enviar/recibir datos en los siguientes pasos del programa.

Pero usar un bloque de paso para un solo bloque de exección es válido, porque todavía se diferencian entre los tipos de excepciones, así que si pones todos los bloques de excepción en uno, no está vacío:

try:
    #code here
except Error1:
    #exception handle1

except Error2:
    #exception handle2
#and so on

Se puede reescribir de esa manera:

try:
    #code here
except BaseException as e:
    if isinstance(e, Error1):
        #exception handle1

    elif isinstance(e, Error2):
        #exception handle2

    ...

    else:
        raise

Así que incluso varios bloques excepto con instrucciones de paso pueden resultar en código, cuya estructura maneja tipos especiales de excepciones.

Todos los comentarios presentados hasta ahora son válidos. Siempre que sea posible, debe especificar exactamente qué excepción desea ignorar. Siempre que sea posible, debe analizar qué causó la excepción, y solo ignorar lo que quería ignorar, y no el resto. Si la excepción hace que la aplicación se "bloquee espectacularmente", entonces que así sea, porque es mucho más importante saber lo inesperado que sucedió cuando sucedió, que ocultar que el problema alguna vez ocurrió.

Con todo lo dicho, no tome ninguna la práctica de la programación como algo primordial. Esto es estúpido. Siempre existe el momento y el lugar para hacer el bloque ignorar todas las excepciones.

Otro ejemplo de paramount idiota es el uso del operador goto. Cuando estaba en la escuela, nuestro profesor nos enseñó goto operador solo para mencionar que no lo usarás, NUNCA. No creas que la gente te dice que xyz nunca debe usarse y no puede haber un escenario cuando es útil. Siempre lo hay.

El manejo de errores es muy importante en la programación. Es necesario mostrar al usuario lo que salió mal. En muy pocos casos puede ignorar los errores. Esto es es muy mala práctica de programación.