views:

103

answers:

4

Hi,

can I get description of an exception caught by

catch(...)

block? something like .what() of std::exception.

+3  A: 

That block might catch an int, or a const char*, or anything. How can the compiler possibly know how to describe something when it knows nothing about it? If you want to get information off an exception, you must know the type.

DeadMG
"How can the compiler possibly know how to describe something when it knows nothing about it?" - +1, but actually, the compiler does know a little bit about it. The exception mechanism must store *some* type information, because it has to match the exception object against catch clauses. But the standard doesn't define this information or provide access to it, it's a hidden implementation detail.
Steve Jessop
+11  A: 

There is one trick you might be able to use:

catch(...) {
    handle_exception();
}

void handle_exception() {
    try {
        throw;
    } catch (const std::exception &e) {
        std::cout << e.what() << "\n";
    } catch (const int i) {
        std::cout << i << "\n";
    } catch (const long l) {
        std::cout << l << "\n";
    } catch (const char *p) {
        std::cout << p << "\n";
    } catch (...) {
        std::cout << "nope, sorry, I really have no clue what that is\n";
    }

and so on, for as many different types as you think might be thrown. If you really know nothing about what might be thrown then even that second-to-last one is wrong, because somebody might throw a char* which doesn't point to a nul-terminated string.

It's generally a bad idea to throw anything which isn't a std::exception or derived class. The reason std::exception exists is to allow everybody to throw and catch objects that they can do something useful with. In a toy program where you just want to get out of there and can't even be bothered to include a standard header, OK, maybe throw an int or a string literal. I don't think I'd make that part of a formal interface. Any exceptions you throw are part of your formal interface, even if you somehow forgot to document them.

Steve Jessop
really nice trick!
tenfour
+1: great idea!
Chubsdad
+2  A: 

If you know you only throw std::exception or subclasses, try

catch(std::exception& e) {...e.what()... }

Otherwise, as DeadMG wrote, since you can throw (almost) everything, you cannot assume anything about what you caught.

Normally catch(...) should only be used as the last defense when using badly written or documented external libraries. So you would use an hierarchy

catch(my::specialException& e) {
      // I know what happened and can handle it
      ... handle special case
      }
catch(my::otherSpecialException& e) {
      // I know what happened and can handle it
      ... handle other special case
      }
catch(std::exception& e) {
      //I can at least do something with it
      logger.out(e.what());
      }
catch(...) {
     // something happened that should not have 
     logger.out("oops");
     }
jdisk
A: 

How we have our exceptions implemented is that, we have our own Exception classes, that are all derived from std::exception..

Our exceptions will contain Exception message, Function name, File name and line where exceptions are generated. These are all useful not just to show the Messages but also can be used for logging which helps to diagnose the Exception quite easily. So, we get the entire information about the Exceptions generated.

Remember exceptions are for us to get information about what went wrong. So, every bit of information helps in this regard..

liaK