Decoupling exceptions from log formatting - c++

Question

In my API I have a small exception hierarchy, derived from std::exception. I have a base class Exception, which provides an error code, file, line, and function. Other more specific exceptions are derived from Exception. For example, one derived class adds a platform-specific error code, as well as a field that identifies which function returned the error code. This is like a simplified version of system_error, but I can't use C++11 features (I'm stuck working with VS2005, and no Boost).
I need to log these exceptions with my logging class. I want the exceptions to be logged in a certain format. After reading various forums online, and reading Boost's Error and Exception Handling Guidelines, I don't think the what function of each exception, or any other virtual function within Exception, is the appropriate place to format the exception for logging. Therefore my what functions just return the name of the class.
When catching exceptions, I often want to catch very general exceptions, usually std::exception, and pass it to the logger. I don't want to catch individual exceptions very often because I am trying to prevent exceptions from escaping the API (the public portion of my API is in C), and there may be several exceptions that could occur. I want to avoid code like:
try { /* blah */ }
catch {DerivedException const& ex) { logger.log(ex); }
...
catch {Exception const& ex) { logger.log(ex); }
So in my logging class, my log function accepts a std::exception argument. It then uses typeid to compare the parameter to the various exception classes, casting to the appropriate type and then calling a logging function specialized for that type of exception. This is essentially the same technique described in this other post.
I use typeid instead of dynamic_cast because dynamic_cast can succeed for any valid downcast, and for code maintenance purposes, I really don't want the order of my if statements in the log function to matter.
So is this a decent design? It feels wrong to me using typeid like this, but I think I have valid reasons to do it. I haven't seen much exception handling "in the wild", since we primarily work with C, so I haven't seen too many approaches to the subject. Are there other ways to decouple exceptions from their log formatting that I should be aware of?
EDIT: What I decided to implement
I took the suggestion of using the visitor pattern, but adapted it to my situation. I wanted to catch std::exception, since those can be thrown as well as my own, but format the log message based on the exception type.
Each of my exception classes derive from my base Exception class and implement the virtual function accept. I created an ExceptionLogger class, which implements an ExceptionVisitor interface providing the visit functions.
The LogFile class has an instance of ExceptionLogger, as well as an overload of its log function that takes an std::exception parameter. In the log function, I try a dynamic_cast to my base type, Exception. If it succeeds, I call the accept function of the exception, otherwise I call the ExceptionLogger::visit(std::exception const&) function directly. Since std::exception doesn't implement my accept function, I needed the dynamic_cast so I could determine if more detailed logging was possible.
I chose to do this instead of a series of if statements checking typeid because:
It's a named design pattern that I can refer future maintainers to
If a maintainer adds a new exception deriving from my Exception base, but forgets to implement a new visit function for that exception, I will still get the logging that was implemented for the base Exception - a file, line number, and function.
If I had implemented the series of if statements, I would've had to fall back to the std::exception logging behavior, which is just to print out the results of what, or I could've tried a dynamic_cast to an Exception.
Of course I would still prefer a compiler error in this situation.

Answer 1

A simpler solution is to rethrow your exception in your central formatting method (see also this answer). You can then catch each exception type there and format it.
class Exception : public std::exception {};
class DerivedException : public Exception {};
void LogThrownException();
void DoSomething()
{
try
{
// Do something, might throw ...
}
catch (...)
{
LogThrownException();
}
}
void LogThrownException()
{
try
{
throw;
}
// Order is important to catch all derived types.
// Luckily the compiler should warn, if a type is hidden.
catch (DerivedException&)
{
std::cout << "DerivedException";
}
catch (Exception&)
{
std::cout << "Exception";
}
catch (std::exception&)
{
std::cout << "std::exception";
}
// ...
catch (...)
{
std::cout << "Unknown\n";
}
}