Is it a good idea to 'wrap' exceptions?

Question

I'm coding a C++ library that dynamically links with POCO C++ library. I extensively use POCO for several things, like sockets, file handling, logging, etc. So, I need to handle the exceptions POCO can throw.

Apart from exceptions related with POCO, my code can throw other exceptions because several reasons (basically, RunTime exceptions). POCO C++ actually contains a RunTimeException class. So, I can use it.

My question is: Should I just rely on POCO exceptions, and allow third parties using my library to directly catch them? The other option would be to create my own set of exceptions, wrapping the POCO Exceptions, and expose them. That way, if I decide to get rid of POCO in the future, I don't need to change that part. Just my wrapped exceptions.

Is there any other no obvious reason to wrap all the POCO Exceptions with my own ones?

Many thanks in advance.

Answer 1

It all depends on what the actual purpose of your library is (and on what abstraction level over/alongside POCO it operates), and why/if you are using POCO as an implementation detail. (Herein I ignore the question if you should or should not handle the exception at your level, lets assume it is a case where you should throw an exception from the perspective of your library)

Your library just happens to use POCO for implementing something

You nowhere expose that detail, and users of your library are generally not expected to use poco or know about it at all

Here you should wrap your excpetions, or if you do not include poco headers in your headers probably completely replace them by your own exceptions.

At a future point you might decide to use something else to implement your libraries functionality; letting POCO exceptions propagate would essentially mean a change in your API that would otherwise not be necessary.

Your library is intended as something "on top of POCO"

Users of your library are expected to use POCO in their code too and you just add something, e.g. convenience functionality/syntax

Here you can assume that users of your library are familiar with POCO and its exceptions and have no problem with catching POCO exceptions since they are probably doing it somewhere else already.

It is extremely unlikely that anytime you will not use POCO anymore.

Nevertheless you should decide on a case to case base whether it is useful for the user to see the POCO exception or one of yours. If you are just a rather thin wrapper and it is clear what underlying POCO functionality is being used, it can be sufficient to just let POCO exceptions propagate.

If otoh you are doing something that is a functionality far enough from any standard POCO things offered, people would maybe not be able to figure out what really went wrong when they see the POCO exception. In that case wrapping can offer additional information that provides the user of your library with more information about what went wrong on the abstraction level of your library.