First, to answer my own question: at least for Python 3 see
https://docs.python.org/3/library/exceptions.html
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
