However, an exception can give more information about a failure, which can be very useful for debugging.
On a related issue, I was thinking about @ridgeworks’s Errors considered harmful, in particular how the “=>” (single-sided unification) works (which throws an exitence_error(matching_rule,_) exception). In the particular code I was working on, a wrong answer is produced if a parameter that’s expected to be sufficiently ground is uninstantiated – so, the correct behavior is to either fail (by an explicit nonvar(Tree)) or to throw an exception. Single-sided unification provides a painless way of ensuring that an uninstantiated variable isn’t passed to the predicate.
A missing item from Prolog’s notion of exceptions is an exception hierarchy, something that both Java and Python have (as well as ways of handling multiple exceptions, combined with a finally that works a lot like setup_call_cleanup/3). The exception hierarchy (such as Python’s) can be somewhat simulated in Prolog by clever syntax in terms, I suppose …