Custom exception class - variable value becoming lost?

[qwertygeek]

Okay, so I'm working on a small application for which I have a custom Exception class, defined as such:

class InvalidTokenException : public exception {

    string error;

public:
    InvalidTokenException() {};
    ~InvalidTokenException() throw() {};

    InvalidTokenException(string s) {
        this->error = s;
    }

    string getError(){
        return error;
    }

    virtual const char* what() const throw()
    {
        return "Invalid Token Exception";
    }
};

The program reads through a text file, tokenizing input. If it comes across an invalid token one of these gets generated and thrown. Because of the recursive nature of tokenizing, an exception frequently has to be thrown, caught, and thrown again.

The weird problem I'm having is this: depending on where in the program I throw the exception, the string s becomes lost. I have debug prints in every catch block that catches one of these and prints ex.getError() before throwing it again, and depending on where I throw the error, I see this:

Opened file : ../../../doc/input.txt for parsing... 

******** Caught invalid token exception in GetNextToken...
 Error was: Invalid Data Token near: 1w

******** Caught invalid token exception in ParseBodyToken: 
 Error was: Invalid Data Token near: 1w

******** Caught invalid token exception in ParseProgToken: 
 Error was: Invalid Data Token near: 1w

******** Caught invalid token exception in GetNextToken...
 Error was: Invalid Data Token near: 1w

Invalid token.  Invalid Parse Data Token near: 1w
Exiting...

However, if I move the invalid token just ONE token further ahead in the input text file...

Opened file : ../../../doc/input.txt for parsing... 

******** Caught invalid token exception in GetNextToken...
 Error was: 

******** Caught invalid token exception in Parse Data Token...
 Error was: 

******** Caught invalid token exception in GetNextToken...
 Error was: 

******** Caught invalid token exception in ParseBodyToken: 
 Error was: 

******** Caught invalid token exception in ParseProgToken: 
 Error was: 

******** Caught invalid token exception in GetNextToken...
 Error was: 

Invalid token. 
Exiting...

I don't understand where my token is becoming lost for a generic token.. I'm building it with a specific string anywhere that it's generated.

I've tried doing it this way:

try {
   // statements
}
catch (InvalidTokenException ex) {
   throw ex;
}

And this way:

try {
   // statements
}
catch (InvalidTokenException ex) {
  throw InvalidTokenException( ex.getError() );  // basically const new one out of old one
}

I can't see any need to use the second method but it was a test after the first method failed.
Does anyone have any suggestions as to why this isn't working?

[laserlight]

Are you sure that the string is "lost" rather than simply empty?

I suggest that instead of deriving from std::exception, you derive from std::runtime_error:

class InvalidTokenException : public std::runtime_error {
public:
    explicit InvalidTokenException(const std::string& message)
        : std::runtime_error(message) {}
};

I have chosen not to provide a default constructor because it could lead to the kind of "lost" message that you see if an exception is accidentally default constructed. Now you would use it as:

try {
    // ...
} catch (const std::exception& e) {
    // Log the exception? Let's print its message as an example.
    std::cout << e.what() << std::endl;
    throw; // re-throw the same exception.
}

[qwertygeek]

It shouldn't be empty as the token that's being parsed is of the same type as the one that successfully prints the output so it's being built in the same place - that being ParseDataToken() - which throws if it encounters something invalid. To be safe I went back and removed the default constructor, and added distinct strings to each of my throw statements. Still coming up empty on ex.getError(). Something very odd going on yes?

I'll take a look at the runtime_error. What's the difference other than the name? (and I can't just catch std::exception, I have to stay a little specific as I have other exceptions to be caught as well..)

runtime_error is definitly a consideration but I'm really confused as to what's up with C++ and the Disappearing String here...

[laserlight]

Originally Posted by qwertygeek

I'll take a look at the runtime_error. What's the difference other than the name?

As you can see from my example, it requires less boilerplate code to setup since you just need to define the constructor without bothering to override what() yourself. As a side effect, you actually get to use what() instead of overriding it in a not so useful way.

Originally Posted by qwertygeek

(and I can't just catch std::exception, I have to stay a little specific as I have other exceptions to be caught as well..)

Sure, but remember to catch std::exception at some point, and possibly also the catch-all (...).

[qwertygeek]

Alright... it was evidently my stringstream... but about this runtime_error, the argument I pass in I assume will get assigned to what prints out when you call what()? That does sound awfully simpler...

[laserlight]

Originally Posted by qwertygeek

but about this runtime_error, the argument I pass in I assume will get assigned to what prints out when you call what()? That does sound awfully simpler...

Yes.