On tis, 2007-08-21 at 19:50 +0200, Erik Johansson wrote:
> 2007/8/21, Anders Olofsson <[EMAIL PROTECTED]>:
> > > The second question is, should we use throw-specifications when
> > > defining methods or simply document which exceptions are thrown?
> >
> > throw() specification on functions looks better to me, that way the
> > compiler can also check if we throw something illegal.
>
> I take it that you don't think we should add std::exception to all
> throw specifications, but set our own std::unexpected handler?
Didn't know about that one but after some googling I must say that
std::unexpected sounds perfect to use. If we are just gonna catch the
critical exceptions in one place anyway it must be better to use it
instead of adding it to throw clause on all functions which will also
allow any non-critical exceptions which we might not want to allow
everywhere.
> > I think std::exception should at least be caugh somewhere and tell the
> > user what happened and, if possible, do some kind of nice shutdown
> > rather than just crash. Stack traces are always nice to get in these
> > situations, in the error log if possible.
> > But anything causing bad_alloc or bad_cast to be thrown is probably
> > hopeless to recover from anyway so no need to add checks everywhere.
> > Otherwise we will just get a lot of meaningless catch(...) { cout << "we
> > got a problem here" << endl; }
>
> Then I can remove the try-catch clause in Licq::Exception's
> constructor?
> http://trac.licq.org/browser/branches/newapi/licq/src/exceptions/exception.cpp
Yes, if you're gonna have that kind of error handling for every call,
we'll have 10 times the size of the code just for all those catch
blocks. Better to have it in one place and make that as good handling as
possible.
/Anders
