In general I am a bit concerned that while I support the general idea, the implementation here just will not scale to the handling of all exceptions in all places in the code and will not therefore be maintainable. E.g. the PR suggests we handle ForbiddenException but what about ExpiredTokenException and NoCredentialsError and every possible other exception the client can throw if you haven't set up your AWS config properly?

I wonder if you should start by reviewing this much earlier PR
#997

In general I am a bit concerned that while I support the general idea, the implementation here just will not scale to the handling of all exceptions in all places in the code and will not therefore be maintainable.

I completely agree that this is addressing a narrow case and that a more general solution is needed. I would argue that:

1. The original implementation was broken, returning None when it should have raised the exception.
2. We needn't let perfect be the enemy of good. This PR fixes the bug and addresses an additional case which is affecting real users.
3. Misleading error messages are expensive and permissions issues are common.

C'mon, it's been forever since I submitted a PR. 😆

@dboitnot Here are some more thoughts:

• Agree that the bug should be fixed and I think I agree about re-raising the exception.
• At a high level design point of view, I think we need to think carefully about whether we want to in general handle exceptions by sending hints back to the caller about how to setup their AWS and so on. Because if we handle this one lone exception this way, and then don't do the same everywhere else, that just gives the tool the feeling of an inconsistent design.
• If we do choose to do this, then I think the exception should be handled here https://github.com/Sceptre/sceptre/blob/master/sceptre/plan/actions.py#L309-L320
  or perhaps somewhere in here
  https://github.com/Sceptre/sceptre/blob/master/sceptre/connection_manager.py ?

Closing in favour of #1530