Re: Standard library exception specifications might be lacking
on Mon Sep 17 2007, rani_sharoni-AT-hotmail.com wrote:
On Sep 16, 5:15 pm, David Abrahams <d...@boost-consulting.com> wrote:
on Sun Sep 16 2007, rani_sharoni-AT-hotmail.com wrote:
I noticed that according to 17.4.4.8 any of the library's functions,
except for destructors, might throw unless specified.
OTOH, I don't see any exception specifications (via throw() or
wording) for functions that intuitively have no-fail guarantee.
[...]
That's intentional. Whether or not it's optimal is certainly open to
debate. When we were adding the exception-safety language, giving
those functions a nothrow guarantee was not deemed essential to
writing exception-safe code, and we were in a period of finalization
where the actual number of words in any change to the standard was of
great concern to many members. Larger proposals stood less chance of
being passed. As it stands they only passed at the last minute, and
by the skin of their teeth, because a couple national bodies refused
to ratify the standard without them.
Nevertheless your accomplishment is groundbreaking.
I understand your point about essentiality but my concern is about
usability. IMHO, assuming that such operations might fail is
placing unreasonable burden on the programmer and no implementation
ever threw for them hence if they'll start throwing the consequences
might be disastrous (and worst - silently).
BTW - I remember that you tested STL implementation using exhaustive
fault injection.
Yes.
Did you actually fail such operations
(e.g. container's non mutating ones)?
In my implementation atop STLPort, the restrictions were often tighter
than what we ended up specifying for the standard
(http://tinyurl.com/32elac) so things like operator[] were usually
specified not to fail and the tests would check for that.
Out of curiosity, is boost tested with fault injection?
Maybe parts, but not the majority.
Can operator[X] fail if X is in the range?
Nope.
Table 89: (Optional sequence container operations) states the
semantics (notwithstanding that the column is mislabelled) as
*(a.begin() + n)
which isn't allowed to throw.
I didn't see explicit no-fail specifications for a.begin() or
iterator::operator+.
Can you point me to such?
Wow, you're right. No such guarantees exist. I was thinking of
[container.requirements}:
"no copy constructor or assignment operator of a returned iterator
throws an exception."
For basic_string (mainly string/wstring) I saw almost no exception
specifications.
Correct.
It's similar to vector and probably requires the same
clarifications.
I'm not sure it *requires* them. FWIW it isn't a container,
officially, so the blanket guarantees that apply to containers don't
apply there and it would have been dangerous to try to add them.
I meant that string/wstring should also probably have explicit
no-fail specifications for some of its operations (e.g. non-mutating
ones and operator[]).
I know what you meant.
[...]
Can't parse that, sorry.
Sorry for not being clear.
I didn't saw exception specifications for algorithms that have,
intuitively, no-fail guarantee for some instantiations. For example,
is for_each allowed to be implemented in away that it will throw for
every use-case (e.g. by internally allocating debugging related object
that might throw)?
Yes. :(
Allowing the implementation too much freedom to throw will make
writing of correct failure-safe code practically impossible so I'm
quite sure that many of the above operations are intended to have no-
fail guarantee (sometime conditional).
The choices were very deliberate, if suboptimal. It's probably a good
time to revisit them, though.
Some people already think that "no-fail iff throw()" not realizing
that it's impossible to program with such requirement so it's better
to clarify that.
Oops; I lost you again. If the standard says throw() it does mean the
operation can't fail.
I'll be happy to file a defect report based on this discussion.
(Howard, please correct me if I'm wrong) I don't think it's
appropriate for a defect report, since we said exactly what we meant,
but I'd be happy to co-author a paper with you, proposing changes.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]