CODEWITHSUNDEEP
c++c++11exceptionthrow
SergeantPenguin
SergeantPenguin

Reputation: 873

Is it important that what() does not throw (exception classes)?

An exercise from C++ Primer asks

Why is it important that the what function [of exception classes] doesn’t throw?

Since there is no way to check my answer I was hoping to get an opinion. I thought possibly that it is an error (maybe terminate would've been called) to throw another exception during a catch clause (other than a rethrow throw;) while the current exception object is still being handled. It seems that is not the case though and it is completely okay to throw out of catch clauses:

#include <iostream>

using namespace std;

int main(){


    try{
        try{
            throw exception();
        } catch(exception err){ throw exception();}
    } catch(exception err){ cout << "caught"} //compiles and runs fine, outputs "caught"


}

So program terminations are not a worry. It seems then, any problem that arises from what() throwing should, at the very least, be rectifiable by the user if they were so inclined.

Maybe then, the importance might be that while handling an error we do not want further unexpected errors to occur? Throws inside catch clauses are mainly intended for sending the exception object further up the call chain. A user may receive an error from deep in his program and does not want to worry that the error caught has to be associated with its own try block. Or maybe what() having its own throw may also lead to recursive effects (e.g. what() throws an exception, then we catch this exception and call what() but this then throws, and so on) meaning it might become impossible to handle any errors? How drastic can it be for what() to potentially throw?

Upvotes: 1

Views: 290

Answers (3)

ead
ead

Reputation: 34347

Image a very curious coder with a slight tendency towards being a control freak (I know a couple of them myself), he really wants to know what is going wrong in his program and logs all errors with ex.what(). So he codes

try {
  code();
}
catch(std::exception &e) {
  std::cout<<e.what()
}

He is pretty pleased with the world in general and with himself in particular. But now it crosses his mind, that e.what() could throw an exception as well. So he is codes:

try{
    try {
      code();
    }
    catch(std::exception &e) {
      std::cout<<e.what()
    }
}   
catch(std::exception &e) {
      std::cout<<e.what()
}

A minute later he notices, that there is again an uncaught exception possible! Remember, he is a control freak, so he is going to write another try-catch block and than another and another

So you can bet any money, his project will be late - how could you do something like this to my friend? So please make sure e.what() doesn't throw:)

I guess it is the reason behind what being noexcept.

Upvotes: 1

ildjarn
ildjarn

Reputation: 62985

std::exception::what() is noexcept. Consequently, if it throws, std::terminate is called. Yes, this is important.

Upvotes: 2

Tom&#225;š Zato
Tom&#225;š Zato

Reputation: 53202

I think there's nothing unclear - it's just as you described. If .what() method of an exception class throws an error, the whole catch effort was wasted:

try {
  someDangerousOperation();
}
catch(std::exception e) {
  // Ooops, instead of false,
  //we get another exception totally unrelated to original error
  someLogClassOrWhatever.save(e.what());
  return false;
}
return true;

And Imagine the crazy code if you were expected to deal with what()'s exceptions:

try {
  someDangerousOperation();
}
catch(std::exception e) {
  // Not very fun
  try {
    someLogClassOrWhatever.save(e.what());
  }
  catch(...) {
    alsoWhatHasFailedThatIsReallyGreat(); 
  }
  return false;
}

I think there's nothing more in that, probably the question is so simple it seems there must be some catch hiding in it. I think it's not the case.

Upvotes: 3

Related Questions