Question 1:
Is is possible to throw an exception that will not be caught by std::exception?
try
{
}
catch(std::exception & e)
{
}
catch(...)
{
//Is this block needed?
}
Question 2:
Is it better to have:
catch(std::exception & e)
Or
catch(std::exception e)
Or
catch(const std::exception &e)//<--- this is the method I usually use
It sure is, you can throw any type you want, and it doesn't need to be derived from std::exception.
Catching a const reference is better. The reason is that you can throw a const or a non-const, and it can be caught by a non-const. Which works like a silent casting away of const.
Q1: yes. you can throw any type, not necessary types that inherit from std::exception.
you can write throw 1; to throw and int or throw "hello"; to throw a char*, both of which do not inherit from std::exception. this is however considered bad practice because the user of the class can't expect you to throw anything. If you don't want to inherit from std::exception what you usually do is create your own exception hierarchy.
Q2: catching an exception by value (2nd option) is a bad practice because you force the exception instance to be copied and in that possibly performing allocations which may cause further exceptions.
Using the first option suggest you intend to change e in the catch block which is also something you'd probably like to avoid because exceptions are usually maintained immutable after creation. The only thing that is left is the third option.
The answer to your second question is that you should throw by value and catch by reference. If you catch by value you may get 'object slicing'.
It is sometimes necessary to throw an exception that does not inherit from std::exception. When shipping a shared library it's best practice to either re-implement or wrap most the std library types instead of exposing methods/functions that use them directly as it can cause all sorts of linker/compiler interoperability issues.