Re: The C++ article in April issue of DDJ
On Mar 19, 8:24 pm, "Andrei Iltchenko" <andrei.ilche...@gmail.com>
wrote:
It has been a while since I last posted to this newsgroup, but the
recent article in DDJ by Gigi Sayfan entitled "Practical C++ Error
Handling in Hybrid Environments" (available athttp://www.ddj.com/dept/cpp/197003350)
left me no choice but to react.
What caught my attention is the "cunning" StreamingException class and
some of the author's comments about its design that are plainly
inaccurate.
I'm not sure about the "plainly".
Here's the class
class StreamingException : public std::runtime_error
{
public:
StreamingException() :
std::runtime_error(""),
ss_(std::auto_ptr<std::stringstream>
(new std::stringstream()))
{
}
~StreamingException() throw()
{
}
template <typename T>
StreamingException & operator << (const T & t)
{
(*ss_) << t;
return *this;
}
virtual const char * what() const throw()
{
s_ = ss_->str();
return s_.c_str();
}
private:
mutable std::auto_ptr<std::stringstream> ss_;
mutable std::string s_;
};
[...]
Here are the comments that are inaccurate:
"The destructor is quite empty, but it can't be dropped. The compiler
will indeed generate a default destructor for you, but the default
destructor doesn't come with an empty throw() exception specification.
This is required because std::runtime_error defines such a virtual
destructor. Exception specifications are an annoying misfeature of C++
that specifies what exceptions a method may throw and are part of the
method signature. Thankfully, they are optional so you don't see them
a lot in the wild. "
This comment is specious as there is no point in overriding the
destructor for the purpose of obtaining an exception specification
that doesn't allow exceptions.
Unless you want the code to actually compile on real compilers.
I know what the standard says, but I've had the problem in the
past (I forget with which compiler); his code may be 100%
standard conformant without the destructor (but so is code using
export), but the destructor is still necessary if you want it to
compile with real compilers.
[...]
The second inaccurate comment concerns the mutability of the 'ss_'
data mameber. Here it goes:
"Okay, so why mutable? Well, the caught exception is a const reference
because the catching code is not supposed to modify the internal state
of the exception. However, auto_ptr with its ownership transfer
semantics does require a change of state. The mutable modifier was
invented exactly for this purpose-being able to modify the internal
state of an object while preserving its conceptual constness."
According to the rules of the language the 'const StreamingException&'
reference in the catch clause is to be either bound directly to the
exception object or to a const temporary object (See 8.5.3/5).
His wording isn't too fortunate, but you do need the mutable.
An exception must be copiable in order to throw it, and without
the mutable, it's not.
[...]
I find it quite sad that a magazine that used to be renowned for the
quality of its articles, didn't put enough effort to catch such
blatant omissions during the article's editing.
As with most such magazines, I find the quality very variable;
IMHO, this particular article was one of the better ones.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]