Repacking exceptions or maintaining their integrity?

Question

I am writing some class that has 2 (basic) subsystems. Part depends on boost :: filesystem, and other part depends on tinyxml. (Basically, it reads xml, and depending on the xml data it uses boost::filesystem functions for more access to other files).

Now both of them can "exclude" exceptions. I am wondering how to handle these exceptions:

The class itself — in most cases — cannot “fix” the exception and must simply throw it away. (The most likely case will be erroneous input from the user).

However, what to do in this case? - boost::filesystem and tinyxml have their own exceptions that are not fully compatible with each other.

Should I expect a user of this class to handle boost / tinyxml exceptions? - For now, all use of these libraries is hidden to the end user.

Should I repackage extensions on my own? I always doubt the repacking, as that means a lot of extra attempts ... blocking the blocks.

What will you advice me?

Answer 1

It is impossible to answer this question without understanding your code and your coding rules, in particular, as they relate to exceptions.

But if your coding rules allow exceptions, then I suggest a general thumb rule:

Allow exceptions to propagate until they reach the context in which they can be handled properly. If they never reach the context in which they can be handled properly, allow your program to crash. Get a core dump and debug the problem.

"Handling" an exception in a specific context may be as simple as translating it into an error code or your own exception class, but in this case you must rebuild the new exception and allow it to propagate to the handler.

Do not use any form of catch handler for all exceptions to prevent application crashes or even to report errors and deaths. Instead, implement a system that will generate dumps in the event of an unhandled exception, and let your program die. The dump itself is enough log. You do not want everything to hang, because your system is in such a damaged state that it cannot be restored from.

Answer 2

I would recommend that your class throw its own exceptions. This way you can provide information hiding, and your class clients will not depend on the libraries that you decide to use.

Answer 3

Do you think this applies to the end user? Because it is related to design.

Some libraries, when used on Windows, have their own data, while you can use other error handling methods to check. For example, sqlite has its own group of error codes, but you can use GetLastError to know why the database was not open.

In your case, the question arises: will you use exceptions in your class? In this case, it is better to provide your own exception. If not, you can allow the user to cache your errors and exception if he wants.

Claudio