That is a perfectly valid (and probably often good) approach, though regardless of whether you react to the error itself or the return value of a function that interrogates the error you have a point of coupling.
I find using an error/exception struct in {:error, %Error{}} tuples provides a good, flexible solution for representing errors that can be used simply in with or an action_fallback or any other error handling situation. Tuples or opaque objects or any similar concept could work just as well, I just presented what I’ve found to be a good solution.
I think the important part is that people should strive to return context rich {:error, reason} tuples instead of just returning {:error, :not_found} or even worse, just returning :error.
