Several operations are undefined because they failed to meet required behavior(ISO C++11 [defns.required.behavior]) at runtime. Currently libstdc++ throw exceptions for them. For example, when object of type std::string being initialized using a null pointer value, an exception of type std::logic_error is thrown by basic_string<char>::_S_construct. That's nothing wrong for libstdc++ on conformance, because an implementation is free to do anything when the behavior is undefined. However, this behavior is somewhat confusing for users not so familiar with the standard. I suggest 2 options for future releases of libstdc++: 1. Make the type of exceptions specific(i.e. as a documented feature), distinguishable with other exceptions required to be thrown by the standard. It can be a type derived from std::logic_error, as an extension. 2. Make the implementation-defined result of what() specific and distinguishable, e.g. some prefix to indicate the exception is not mandated. This is not only good for manually distinguishing UB, but also beneficial for tests on conformance/portability of user programs.
(In reply to frankhb1989 from comment #0) > is somewhat confusing for users not so familiar with the standard. I'm not convinced by this. Doing something like passing a null pointer to std::string is a mistake. Whether we throw an exception of one type or another type, or abort, or segfault, the user needs to fix their code. I don't see why adding a new type (along with its typeinfo and vtable) to the library will make it any easier. I don't see why the user should care that our method of reporting their mistake is specific to our implementation, they still need to fix the mistake. Good messages in what() are helpful, but we don't need a new type with a special prefix for that.