In defensive programming, guard clauses are used to protect your methods from invalid parameters. In design by contract, guard clauses are known as preconditions, and in domain driven design, we use them to protect invariants -- unbreakable rules that form assumptions about our model:
Unfortunately, in examples like this, the true intention of the method - actually withdrawing money - is now lost in a forest of error-checking guard clauses and exception messages. In fact, the successful path -- representing 99% of executions (when there is enough money) -- only accounts for 1 line in this method. So let's refactor: By extracting these guard clauses into separate guard methods, the intention of the method becomes much clearer, and the explicit method names give a clear indication of what is being checked inside (regardless of how those checks are implemented). And we can concentrate on the main success path again.