Re: Usage of throw
* Olivier Delannoy:
Hi all,
I am interesting in adding contextual information (such as file/line)
in debug mode and not in production mode. In order to do that I plan
on adding a macro of the form :
MY_THROW(exp) which is going to be translated into :
- in release mode: throw (exp)
- in debug mode: throw (exp).context(__FILE__, __LINE__)
In order to do that I need to make sure all my exception provide a
context method of the form :
class MyExp
{
...
public:
MyExp& context(char* file, int line) { ... ; return *this;}
};
Technically the above is OK, but there are several higher level issues.
First, starting at the top, MY_THROW as a macro encapsulates what may be
the Entirely Wrong (a.k.a. EW) thing. As far as I can see there's no
real advantage to encapsulating the throw action itself, and some
disadvantages, especially that this is less transparent and clear to
someone reading the code, and that it makes for inconsistent style e.g.
where re-throwing is required. Instead, I suggest encapsulating the
gathering of source code context information, like
#define THIS_PLACE Place( __FILE__, __LINE__ )
Second, there are practical advantages to have MyExp derive directly or
indirectly from std::exception. I suggest deriving it from
std::runtime_error. That will support code that (risky, I don't
recommend it) treats other standard exceptions as more or less "hard"
ones, catching only std::runtime_error and letting others propagate.
Third, regarding the context() function, you cannot throw a reference:
all throwing is by value, formally invoking a copy constructor. So what
this function achieves is (1) to reduce severely the guarantees that
MyExp can offer and rely on (that an instance does carry a valid
filename and line number), and (2) to make it more difficult for the
compiler to optimize throw statements, i.e. you have a higher risk of
two constructor calls (default construction + copy construction, plus of
course the context() call) instead of just one. So I strongly suggest
replacing context() with a proper constructor, e.g. taking a Place as
argument.
There are more such issues, but I think the above is enough to get you
going.
Now in a test program I do:
void f()
{
MY_THROW(MyExp()); // In Debug mode: throw
(MyExp()).context(__FILE__, __LINE__);
}
int main()
{
try
{
f();
}
catch(MyExp& e)
Technically "MyExp&" is OK.
But at a higher level it indicates that you need the exception object to
be non-const, that you're going to modify it, so I suggest adding a
const here, "MyExpt const&".
If only C++ had "const" as default!
{
// Do something with e
}
}
This program works nice but I don't feel confortable with this kind of
use of throw. Is it safe/portable accross compiler/ in respect of
standards to throw an exception as I do ?
Technically yes, but see above.
Is there any better way to do this ?
Yes.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]