Personally, here is what I do: if access control is part of the business model, then I put it in the context and, almost always, I raise. Otherwise, continue doing it in plugs. That's it!
For web apps, you should almost never be triggering these invalid access control state, because it means the UI is allowing users to do something they are not really supposed to do. If the user cannot delete a resource, then the button most likely shouldn't show up (or it should be disabled with a comment) etc.
Raising actually helps us find these bad UI paths too because I get an error I can act on.
Now let's say you do want to handle some of these errors. You have three options:
1. Continue raising and rescue in the controller (meh)
2. Continue raising and implement Plug.Exception for said exception so you control how they are shown to the user (great if they are still general exceptions)
3. Return {:ok, _} | {:error, ...} and handle it in the controller (or in the FallbackController for APIs)
For web apps, you should almost never be triggering these invalid access control state, because it means the UI is allowing users to do something they are not really supposed to do. If the user cannot delete a resource, then the button most likely shouldn't show up (or it should be disabled with a comment) etc.
Raising actually helps us find these bad UI paths too because I get an error I can act on.
Now let's say you do want to handle some of these errors. You have three options:
1. Continue raising and rescue in the controller (meh)
2. Continue raising and implement Plug.Exception for said exception so you control how they are shown to the user (great if they are still general exceptions)
3. Return {:ok, _} | {:error, ...} and handle it in the controller (or in the FallbackController for APIs)