First, to answer my own question: at least for Python 3 see

Only exceptions not catch by "except Exception:" are SystemExit, KeyboardInterrupt and GeneratorExit.

Hence only real difference between "except Exception:" and "except:" is that latter one blocks Ctrl+C. At least MemoryError and RecursionError can happen so that outer level code with "except Exception:" might do something wrong. Artificial but theoretically possible example:

If we have a recursive function to get a Hamiltionian cycle of a graph, and is_hamiltonian() calls that, it shall of course make difference between ValueError from non-hamiltonian graph and RecursionError from too big graph. If it just tries to find a cycle and catch any error, it will return False for too big graph.

On Wed, 12 Oct 2016, 'Martin R' via sage-devel wrote:

wouldn't it make sense to catch "everything reasonable"?  I could imagine
that for some reason at some point it is decided that the method you call
raises a slightly different error.  Would that be bad?

Something like my example can then happen.

On Wed, 12 Oct 2016, Daniel Krenn wrote:

IMO a ValueError is better than a TypeError because topological_sort
(implicitly) takes the DiGraph as an input, and the input type is
correct, just its value is wrong.

I agree that a ValueError is better than a TypeError. IMHO even better
is a (special) RuntimeError, as checking if it contains a cycle needs
(at least somehow) the sorting. Thus it happens when the algorithm has
already started.

But the documentation for RuntimeError says "Raised when an error is detected that doesn’t fall in any of the other categories." Does not sounds to be used here.

So we have now a common view that 'type' in TypeError should (mostly?) refer to types in wrong class, wrong category etc; and so for functions having no input it should (almost?) never happen.

Jori Mäntysalo

Reply via email to