title: Questions on Exception Specification and Application Design
body: <p>Although this topic has been extensively discussed on SO, I'd like to clarify a few things that are still not clear to me so, considering the following facts:</p>
  
  <ol>
  <li><p>10 years ago, Herb Sutter was telling us to <a href="http://www.gotw.ca/publications/mill22.htm" rel="nofollow noreferrer">refrain from using this functionality</a>.</p></li>
  <li><p>Specifying the possible exceptions that a function / method may throw does not force the compiler to yell at you when you decide to change the function's body and throw a new type of exception, forgetting by mistake to change the exception specification in the function's declaration.</p></li>
  <li><p>If you have a very high level function that calls several other high level functions, which each run tons of code to produce the results, then I can imagine the maintenance from hell nightmare, when I would have to specify ALL the errors which the first function may throw, and this list would have to include all the exceptions the inner functions may throw and so on, thus creating tight coupling between high and low level functions, which is quite undesirable. On the other hand, we derive all exceptions from std::runtime_error, which <a href="https://stackoverflow.com/a/1158134/1174378">we know is a good practice</a> and we could specify that the high level functions just throw std::runtime_error and be done with it. But wait a minute... Where do we actually catch the exceptions? Would it not be rather odd / nasty / bad to enclose a call to one of these high level functions in a try / catch block, which catches a MyVerySpecific exception, when the high level function is supposed to throw only std::runtime_error??? Would it be any good to catch specific exceptions in lower level functions, which are not able to do anything about them but pass them on in a more generic container, with more information appended to them? I certainly don't want to write try / catch blocks in every function that I write, just to format exceptions. It would be like requiring every function to validate its parameters, and that can drive people insane, when they need to change something in a low level function.</p></li>
  </ol>
  
  <p>Questions:</p>
  
  <ol>
  <li><p>Do Herb Sutter's rants about exception specification still hold today? Has anything changed since then? I am mostly interested in pre-C++0x standards. If yes, I guess we can consider this topic closed. </p></li>
  <li><p>Since it seems that the compiler mostly ignores these exception specifications, and when catching exceptions, in 99% of the cases, one would use <code>catch (const CustomException &amp;ex)</code>, how would one specify that a function throws CustomException? <code>throw(CustomExecption)</code> or <code>throw (CustomException &amp;)</code> or <code>throw (const CustomException &amp;)</code>? I have seen all variations, and, although I would go for the first one, do the others make any sense / add any benefits?</p></li>
  <li><p>How would one actually use this functionality, and, at the same time, avoid the fallacies illustrated in the above 3rd fact?</p></li>
  <li><p><strong>EDIT:</strong> Suppose that we're building a library. How will its users know what exceptions to expect, if we don't use exception specification? They will certainly not see what functions will be called internally by the API methods...</p></li>
  </ol>