<p>In C++, you can specify that a function may or may not throw an exception by using an exception specifier. For example:</p>

<pre><code>void foo() throw(); // guaranteed not to throw an exception
void bar() throw(int); // may throw an exception of type int
void baz() throw(...); // may throw an exception of some unspecified type
</code></pre>

<p>I'm doubtful about actually using them because of the following:</p>

<ol>
<li>The compiler doesn't really enforce exception specifiers in any rigorous way, so the benefits are not great. Ideally, you would like to get a compile error.</li>
<li>If a function violates an exception specifier, I think the standard behaviour is to terminate the program.</li>
<li>In VS.Net, it treats throw(X) as throw(...), so adherence to the standard is not strong.</li>
</ol>

<p>Do you think exception specifiers should be used?<br>
Please answer with "yes" or "no" and provide some reasons to justify your answer.</p>

Generally I would not use exception specifiers.  However, in cases where if any other exception were to come from the function in question that the program would definitively be unable to
correct
, then it can be useful.  In all cases, make sure to document clearly what exceptions could be expected from that function.
Yes, the expected behavior of a non-specified exception being thrown from a function with exception specifiers is to call terminate().
I will also note that Scott Meyers addresses this subject in More Effective C++.  His Effective C++ and More Effective C++ are highly recommended books.