sino sentencias programacion operador not hacer ejemplos diferente condicionales condicional como anidado python exception raise built-in

sentencias - ¿Está bien plantear una excepción incorporada, pero con un mensaje diferente, en Python?



si anidado en python (3)

¿Está bien plantear una excepción incorporada con un texto personalizado? ¿O para elevar una advertencia incorporada también con texto personalizado?

La documentación dice:

excepción ValueError: se genera cuando una operación o función incorporada recibe un argumento (...)

¿Está implícito que solo las operaciones integradas deben generar una excepción ValueError?

En la práctica, entiendo que es seguro crear una clase de excepción que hereda de ValueError o Exception. Pero, ¿está bien no hacerlo y elevar directamente un ValueError ("texto personalizado")?

Dado que ValueError está integrado, al generar un ValueError (con un texto personalizado), los usuarios pueden ver rápidamente qué tipo de problema está involucrado, en comparación con un tipo de excepción personalizado (algo como "ValueErrorSpecificModule", que no es estándar).


Está bien y lo hago todo el tiempo. Me parece menos sorprendente ver TypeError que MySpecialTypeError en muchas situaciones.

En la página que has vinculado , no veo la frase "incorporada":

exception TypeError: Raised when an operation or function is applied to an object of inappropriate type. The associated value is a string giving details about the type mismatch.

Quizás alguien haya visto tu pregunta y ya haya arreglado la documentación.
EDITAR: Parece que puede haber insertado la documentación para ValueError lugar de TypeError


Está perfectamente bien.

Sin embargo, es posible que desee crear su propia subclase para ayudar a distinguir de las excepciones integradas

Por ejemplo, si tiene algo que funciona como un dict , puede generar un KeyError por los motivos habituales, pero ¿qué sucede si KeyError realmente proviene de un dict subyacente que está utilizando en la implementación?

Subir una subclase de KeyError hace que sea más fácil ver que hay un error en la implementación, y no que la clave simplemente no esté en su objeto


No hay nada operativo incorrecto en hacer algo como:

raise ValueError("invalid input encoding")

De hecho, lo hago muy a menudo cuando escribo la primera pasada de algún código. El principal problema al hacerlo de esa manera es que a los clientes de su código les cuesta mucho ser precisos en su manejo de excepciones; para capturar esa excepción específica, tendrían que hacer una coincidencia de cadenas en el objeto de excepción que capturaron, lo que obviamente es frágil y tedioso. Por lo tanto, sería mejor introducir una subclase de ValueError propia; esto todavía podría ser capturado como ValueError, pero también como la clase de excepción más específica.

Una regla general es que siempre que tenga un código como:

raise ValueError(''some problem: %s'' % value)

Probablemente debería reemplazarlo con algo como:

class SomeProblem(ValueError): """ Raised to signal a problem with the specified value. """ # ... raise SomeProblem(value)

Podría decir que el tipo de excepción especifica qué salió mal, mientras que el mensaje / atributos especifican cómo salió mal.