Return a dynamic string from std::exception's `what`

Question

I'm convinced at this point that I should be creating subclasses of std::exception for all my exception throwing needs. Now I'm looking at how to override the what method.

The situation that I'm facing, it would be really handy if the string what returns be dynamic. Some pieces of code parse an XML file for example, and adding a position or line number to the error message is useful to me.

I am trying to follow the Boost Exception handling guidelines.

What I'd like to know:

• what returns a const char *, which implies any catcher is likely not going to free the string. So I need some other place to store the result, but where would that be? (I need thread-safety.)

• what also includes throw() in its signature. While I can prevent my what from throwing anything, it seems to me that this method really isn't intended for anything too dynamic. If what is not the right place, then where should I be doing this instead?

---

From the answers I've gotten so far, it looks like the only way to accomplish this is by storing the string in the exception. The Boost guidelines recommend against this, which is confusing to me, because std::runtime_error does just that.

Even if I were to use a C-string, I'd have to use a statically sized buffer, or do memory management which can fail too. (I'm wondering if this is actually the only thing that can go wrong in std::string's copy-constructor. That would mean I won't gain anything using dynamically allocated C-strings.)

Is there any other option left?

Answer 1

Well, no problem, you can simply implement the constructor of your derived exception class to format the string you'll return from what(). Free the buffer you use for that in the destructor.

Answer 2

My exception classes generally don't have anything but the constructor and look along these lines:

class MyEx: public std::runtime_error 
{
public: 
    MyEx(const std::string& msg, int line): 
        std::runtime_error(msg + " on line " + boost::lexical_cast<string>(line)) 
    {} 
}; 

An arbitrary example, but it is the base class that handles managing the what() message.

But if you want to, you can also only assign the base part of the exception object, after you've put together the message in the constructor body.

#include <stdexcept>
#include <string>
#include <sstream>

class MyEx: public std::runtime_error
{
public:
    MyEx(const std::string& msg, int line):
        std::runtime_error("")
    {
        std::stringstream ss;
        ss << msg << " on line " << line;
        static_cast<std::runtime_error&>(*this) = std::runtime_error(ss.str());
    }
};

#include <iostream>
int main()
{
    try {
        throw MyEx("Evil code", __LINE__);
    }
    catch (const std::exception& e) {
        std::cout << e.what() << '\n';
    }
}

---

However, regarding the boost's guidelines, perhaps you should pay attention to the point that numeric data (positions and lines) might best be made available as numbers through other methods. The guidelines say to worry less about the what() message.

Answer 3

Boost's guidelines appear to be based on two assumptions: copying the exception object might throw another exception, and the what() string isn't a robust or reliable tool. These are valid concerns if you're writing a library that will see wide use in a variety of environments. If you have better knowledge of how the exception will be used, you can judge if these concerns are justified or much ado about nothing. Programming is all about a series of tradeoffs, and the tradeoffs that make sense for the Boost developers might not apply to you.

Answer 4

I'm accepting UncleBens' answer, because I consider it technically the most correct and complete answer to my original question.

For reference, I actually picked a different solution, and stopped using what altogether. I've refactored the code I have now to use something like this as the base exception class:

struct Exception : public virtual std::exception
{
  virtual const char* what() const throw()
  {
    try {
      return typeid(this).name();
    }
    catch (const std::exception& e) {
      return "<unknown exception>";
    }
  }

  // Extended description; may throw.
  virtual void describe(std::ostream& out) const = 0;
};

Basically just filling what with the most meaningful thing I could find without bothering with it anywhere else. I'm going to see how this fares, I guess.

Answer 5

The best way to solve this issue, is steal the code.

The enlightening point for me, was realizing that one could mute the strings. It seemed like magic at the time. Mark did a bang up job on this one.