title: Throwing business exceptions
body: <p>To invoke external services such as payment gateways I create a provider assembly such as: MyCompany.Providers.Braintree, which encapsulates all the logic related to making the service invocation. It works basically as pass through and it is contained in is own assembly.</p>
  
  <p>Let's say the provider has a "DoPayment" method which invokes a service on the gateway which returns a couple of status as well as a body message:</p>
  
  <ul>
  <li>code 111 -> Payment was successfully</li>
  <li>code 222 -> Not enough funds</li>
  <li>code 333 -> Unknown payee</li>
  </ul>
  
  <p>Should the provider throw a "business" exception when the payment has not completed successfully, or should the service basically return a type which wraps what the gateway returned?</p>
  
  <p>I have always opted out for not throwing exceptions in these kind of situations because basically this is not ab exception case - the gateway processed the request successfully (the request was processed even thought the payment was not completed) this process is Microsoft's recommendation as well:</p>
  
  <p><a href="https://msdn.microsoft.com/en-us/library/ms173163.aspx" rel="nofollow">Creating and Throwing Exceptions (C# Programming Guide)</a></p>
  
  <blockquote>
    <p>Exceptions should not be used to change the flow of a program as part of ordinary execution. Exceptions should only be used to report and handle error conditions.</p>
  </blockquote>
  
  <p>Martin Fowler also has opinions on the matter, <a href="http://martinfowler.com/articles/replaceThrowWithNotification.html" rel="nofollow">Replacing Throwing Exceptions with Notification in Validations</a></p>
  
  <blockquote>
    <p>Exceptions signal something outside the expected bounds of behavior of the code in question</p>
  </blockquote>
  
  <p>But it's related to input validation.</p>
  
  <p>What do you guys do?</p>