Design of Poco::Exception class

[ahtoh]

I have several quistions about Poco::Exception base class. Please, could anybody explain me:
1) What is a reason to use throw() in the some functions' signatures of Poco::Exception class? I noticed only virtual functions have that kind of signature.
2) Why are not all additional functions declared as virtual, such as message(), displayText(), nested(), and code()?
3) Why is any exception in the hierarchy of Poco exceptions not using virtual inheritance?

I ask about this, because I have found myself in a situation where I need to have three kind of exception classes, two of them have some additional personal data and third has data from the both foregoing.
Obviously, I have options to implement this, my first thing was to create base class for each of the two with virtual inheritance from Poco::Exception (question 3).
When I started implementing third class using multiple virtual inheritance from the two bases it has never worked, because of nonvirtual stuff (question 2).

My next idea was to create my own base exception class, for this reason I examined the interface of Poco::Exception class carefully and found that only this class has members with throw() in their signatures (question 1).
Whole library except exception classes does not have throw() in members signatures, so I think this has a reason and I am not fully understand exception mechanism espeically from crossplatform point of view.

Now, I consider about creating two base class for special data, and then using nonvirtual multiple inheritance from Poco::Exception and my base classes.

Thanks for you answers in advance.

[alex]

1) What is a reason to use throw() in the some functions' signatures of Poco::Exception class? I noticed only virtual functions have that kind of signature.

Because they are std::exception overrides.

2) Why are not all additional functions declared as virtual, such as message(), displayText(), nested(), and code()?

Because they return Poco::Exception members; what would be the purpose of making them virtual?

3) Why is any exception in the hierarchy of Poco exceptions not using virtual inheritance?

Because there is no multiple inheritance in the Poco exception hierarchy.

[ahtoh]

1) What is a reason to use throw() in the some functions' signatures of Poco::Exception class? I noticed only virtual functions have that kind of signature.

Because they are std::exception overrides.

It is not true, according to the http://www.cplusplus.com/reference/exce ... =exception, only what method and destructor have this signature.
However className and name methods have the same signature.

2) Why are not all additional functions declared as virtual, such as message(), displayText(), nested(), and code()?

Because they return Poco::Exception members; what would be the purpose of making them virtual?

Declaring displayText method as a virtual method has sence, because it allows users who wants to create own excpetions to override algorithm which compiles whole message.
Also it has sense because it allows to call these methods unambiguously in multiple inheritance scenarios.

3) Why is any exception in the hierarchy of Poco exceptions not using virtual inheritance?

Because there is no multiple inheritance in the Poco exception hierarchy.

It is an obvious explanation. Although I am not shure, but I think that if exception classes inherite base class virtually it does not affect on nothing, because handling exceptions significantly harder procces than one additional inderection to access members of base class. At the same time it allows to use these classes as base classes in case of multiple inheritance if somebody wants to do it.

[alex]

only what method and destructor have this signature. However className and name methods have the same signature.

There may have been a reason for it in the past, I'm not sure. If you want it changed, run tests, submit a pull request and we'll look into it.

Declaring displayText method as a virtual method has sence, because it allows users who wants to create own excpetions to override algorithm which compiles whole message.

there are Exception::message(const std::string&) and extendedMessage(const std::string&) protected functions.

I think that if exception classes inherite base class virtually it does not affect on nothing, because handling exceptions significantly harder procces than one additional inderection to access members of base class. At the same time it allows to use these classes as base classes in case of multiple inheritance if somebody wants to do it.

propose a change, submit pull request and we'll consider it.