On Thu, 13 Oct 2016, Jeroen Demeyer wrote:
So we have now a common view that 'type' in TypeError should (mostly?)
refer to types in wrong class, wrong category etc
For Sage, I would certainly add "wrong parent" to this.
True. And there might be some, eh, exceptions to this rule. But mostly
.is_something() should not raise TypeError and sentences like "The poset
is expected to be bounded." in docstring should mean that non-bounded
poset will not raise TypeError.
Python also uses TypeError to indicate a function which is called with
the wrong number of arguments or bad keyword arguments:
str(foo=1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'foo' is an invalid keyword argument for this function
I didn't notice that. I would have expected more exact exception for
those.
elements = D.topological_sort()
More bikeshedding: in this case, I would even consider ArithmeticError. It's
not strictly arithmetic, but it does indicate a mathematical issue. I tend to
use ArithmeticError for mathematical errors (something doesn't work because
it is mathematically not defined) and ValueError for programming errors (an
input which a priori does not make sense).
Documentation for ValueError says "- - and the situation is not described
by a more precise exception - -". Maybe there should be something like
MathematicalError as a base class instead of ArithmeticError, but we can't
change that.
--
Jori Mäntysalo
