On (not) exposing internal exceptions from e.g. networkx

[Tomaz-Vieira]

Some exceptions raised by transfomnd come from internal libraries, like e.g. networkx :

try:
    seq = graph.get_sequence(B, A)
except networkx.exception.NetworkXNoPath:
    ...

This means that if downstream code wants to handle specific failure modes, then it must except on those internal errors, with all the baggage that such a thing entails; in particular it silently makes those internal implementation details essentially part of the transformnd API, and changing the internal implementation (or even catching and wrapping those errors on later versions) could be a breaking change for downstream code, since the except paths will stop working.

My personal, unpopular opinion is that we might as well just return errors instead of raising exceptions, so they are visible in the function signature. It's a bit un-pythonic or whatever, but it is extremely clear. Otherwise, maybe you could consider catching and wrapping those errors into custom, stable ones that can be safely excepted on in client code?

[clbarnes]

I agree with the sentiment. Python error handling is generally a bit of a pain because I find too much ends up under a ValueError or TypeError, which makes it hard to find where the problems actually come from, and in many cases it's hard to find exactly which exceptions could be raised by any particular call.

I also like the return-error-variant system used in rust but would resist using it for this one library when python as a whole doesn't.

As a halfway house, I would support transformnd-specific errors wherever non-builtin errors are currently caught (or expected).

Issue here #76