Handle type error when navigating

[marcuslimdw]

In the event that target does not satisfy the type hint for to, the user will get an UnboundLocalError for path, which is confusing. This PR explicitly handles the case where to gets an input of an unexpected type.

[rodja]

Thanks for the PR, @marcuslimdw. This is only one special case. If we implement this, we should do it for the entire public API. And that is quite a lot of code which needs to be written, tested and maintained. Maybe it's better to rely on static type checkers like mypy to catch such errors.

[marcuslimdw]

@rodja I agree that, in theory, all projects should incorporate static type checkers, because what can be checked before runtime should be checked before runtime.

From a user experience perspective, IMO, it is likely that sooner or later, a user will run into this (which is basically a pattern matching failure) and be confused by the UnboundLocalError, so the question is - is the maintenance burden worth the easier debugging?

Lastly, it's apposite to note that even in the stdlib, there is a function provided for this exact case: assert_never, which might be better than a custom error.

[falkoschindler]

Thanks for the pull request, @marcuslimdw!

We came to the conclusion that raising a TypeError in an else block is a good idea. While it improves the error message for the user, it also improves code readability, since it is a clear indication that path will be defined after the if-elif-else block. I just shortened the error message a little to avoid the risk of it getting outdated in case we change the set of supported types in the future.

There are lots of other places where wrong input types lead to weird exceptions. But we won't be able (and willing) to address all of them. This issue is a great example for the value of static type checkers and linters like mypy and pylint.