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

Reply via email to