Consider the following situation: I have a library that includes a third party library. This third party library throws very nice, useful exceptions derived from std::exception. I’d like to communicate these exceptions to the code that calls my library, but I don’t want to have to include the 3rd party library in the calling code, too. That 3rd party library could potentially change later on.
It seems to make sense to create my own classes in my library that inherit from the third party exceptions, like so:
class myException: public thirdParty {};
Is there an easy way to catch an instance of thirdParty and copy it to myException? Later I may add capability to myException, but for now, I really just want to make thirdParty available to the calling code without including third party’s library there.
I do realize, of course, that the calling code will know about thirdParty because the headers from the third party library get included in my library header, which gets included in the calling code. But I’m trying to establish a contract that says, “Hey, these are the exceptions MY library throws. Later, I may swap out the third party lib, but I’m still going to throw exceptions that do what its exceptions did.”
Is this right? Is there a better way of doing this? Should I just have my calling code be aware of thirdParty exceptions?
If the aim is to reduce coupling with the third party library then you should consider your code as the boundary. As such you wouldn’t leak the implementation to your users.
The question is why do your users need to care about the exception that that the third party library throws? They should care about your code’s abstractions and interfaces.
So I would not inherit from the those exceptions, rather I would create a series of exceptions that reflect the exceptions I want my code to throw. You can give them the same names but you should be the owner of those exceptions.