Hi all,
In Licq 2 the plan is to use exceptions, at least internally within
the daemon (to have or not have exceptions in the public api is
another discussion). My question is how you think we should do it. Any
best practices?
There are at least two ways to define exceptions:
1. A separate exception hierarchy, or
2. internal exception classes.
The first would be something like this:
namespace Licq {
class Exception : public std::exception {};
class SystemException : public Exception {};
class BadArgumentException : public Exception {};
// etc.
}
and then second would be something like this:
namespace Licq {
class BaseException : public std::exception {};
class Plugin {
public:
class Exception : public BaseException {};
// ...
};
class Owner {
public:
class Exception : public BaseException {};
// ...
};
// etc.
}
I think that 1 will give fewer and more general exception classes, but
will mean more work when adding a new exception. 2 on the other hand
makes it easy to add new exceptions so that you can add a
BadPluginIdException and BadPointerArgException instead of just
throwing BadArgumentException. Of course, the first two may inherit
from BadArgumentException and give us a combination of 1 and 2.
The second question is, should we use throw-specifications when
defining methods or simply document which exceptions are thrown?
How should we handle low-level exceptions, such as out-of-memory?
Simply ignore them since we're screwed anyway, or catch them as soon
as possible and try to do something intelligent (what ever that is)?
All comments appreciated.
// Erik
--
Erik Johansson
http://ejohansson.se/
