On Mon, May 23, 2016 at 08:11:10AM +0000, Stefan Krah wrote:
Greg Ewing
writes: So I propose that InvalidOperation be changed to inherit from ValueError, to match the expected behaviour from other numeric types.
Related to this, is there any good reason that ArithmeticError doesn't derive from ValueError?
For Decimal at least, Overflow, Underflow, Clamped etc. don't really map to ValueError.
I think they do. Take Overflow:
py> Decimal("1e500000")**2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
decimal.Overflow: [
This includes InvalidOperation, which unfortunately *already* has a subclass ConversionSyntax for the use case that came up here.
ConversionSyntax, however, is designated by the standard to be a "condition" rather than a "signal", so ConversionSyntax isn't raised -- it just exists, and in the C version you can see the "condition" in the list next to the exception that was raised.
Adding a ValueError to all that just complicates things further. I wouldn't mind raising ConversionSyntax directly, but then again no one knows about that either and it's a small deviation from the standard.
I don't believe the standard says anything about class hierarchies for traps. It explicitly says: "This specification does not define the means by which flags and traps are reset or altered, respectively, or the means by which traps are effected." http://speleotrove.com/decimal/damodel.html#backref.11 As far as the standard itself cares, making InvalidOperation a subclass of ValueError is no better or worse than making InvalidOperation a subclass of Exception. -- Steve