Re: Exception specifications unfortunate, and what about their future?
on Wed Dec 17 2008, Eugene Gershnik <gershnik-AT-gmail.com> wrote:
On Dec 12, 4:52 pm, David Abrahams <d...@boostpro.com> wrote:
on Fri Dec 12 2008, Eugene Gershnik <gershnik-AT-gmail.com> wrote:
On Dec 10, 7:39 am, David Abrahams <d...@boostpro.com> wrote:
In case of exceptions such useful base interface does not exist in
any
language[1]. An no std::exception is not it. Its "interface" is
somewhat equivalent to uber-objects of OO languages. That is it is
mostly useless.
In the case of exceptions, the vast majority of clients are expected
to
use the (empty) interface.
Then we probably define the word 'client' differently in this context.
For me a client is a piece of code that writes 'catch'. Vast majority
of such clients *should* care about more than an empty interface even
if all they do is log and abort.
Okay, but that makes it a very poor analogy to static function signature
checking. The reason I oppose static checking of exceptions at a
function granularity is precisely *because* the client of any non-empy
interface is so far removed, and separated by many many call layers of
function that have no interest in the non-empty interface.
or get a decent user-level error message out of it.
For decent user-level error messages, you'd better not try to build
formatting into the exception object anyhow.
Precisely. Which implies that formatting code has to have some
knowledge of the exception type beyond the common interface.
Yes it does. However, as I've said, while sub-standard error messages
are bad, they don't tend to have any affect on data integrity.
And, unfortunately, exceptions don't even have to derive from it.
Why should they have to? The common interface is empty.
So how do you handle such an exception by relying on this common
interface?
You don't; you do a dynamic downcast. That's essentially what a catch
block is. If every exception author kept to the convention of deriving
from std::exception and publishing their unique what() strings, I'd be
inclined to use something like:
handlers[e.what()](e);
where handlers is a mapping from strings to exception handlers that do
the downcast internally (easily created on-the-fly with a template).
Let's think about what happens when you *are* forced to derive all
exceptions from a given base class and you have statically-checked
exceptions. Then you can write throws(exception_base) and the
specification is always satisfied. It doesn't tell the client anything
interesting about the specific exception type. So in a way, those two
features cancel one another out. If I had to chose one, I'd prefer the
enforced common base because it has some obvious utility (you can rely
on the idiom above and the catch blocks all become simple).
Still, apparently this information is necessary and somebody has to
work on compiling and maintaining this documentation anyway. When
he gets it wrong people fill the internet with question like 'Why
FooBar API doesn't return E_PROBLEM when documentation says it
should?'.
Interesting. I've never, ever seen such a question asked about a C++
interface that uses exceptions.
Well not this exact one, obviously, but a quick Google search on
'vector exceptions' brings questions like
- "What are the exceptions that the vector template throws? For
example, when it runs out of memory?"
- "can I be sure, that push_back throws bad_alloc or a similar std
exception?"
In other words, "what does the documentation say?" Do you consider that
equivalent to "why doesn't the code do what the documentation says?"
among the results just on the first page. You can also try googling
for 'boost why is exception thrown'.
None of that looks like the same question to me either.
So why would it be wrong to have the compiler help this poor guy?
;-)
Because the cost of taking advantage of that help outweighs any
correctness advantages it might offer, which incidentally are very
few.
This I think is the main point of disagreement. Unfortunately nobody
can prove the truth or falsity of this statement at this time.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]