What does try and finally mean in C plus plus programming?

Answer 1

You mean try and catch. There is no finally in C++; it is not required because RAII (Resource Acquisition Is Initialisation) renders it redundant.
A try block provides the primary means of handling runtime errors in C++:

int main () {
try {
std::string().at(1); // throws!
} catch (const std::exception& e) {
std::cerr << e.what () << std::endl;
}
}


Example output:
invalid string position


A catch block is an exception handler for a given type of exception. Every try block must have at least one catch block but we can have as many catch blocks as required to handle different types of exceptions and deal with each one accordingly. The std::exception class is just one type of exception.

The point at which an error is detected can often be quite far-removed from the point at which the error can be handled. The above example isn't the sort of code you'd find in a real-world application; it's fairly obvious where the problem lies because we deliberately forced an exception to be thrown via the tryblock and the error message is reasonably self-explanatory. But in the real-world we're more likely to see code similar to the following:

int main () {

try {

do_a_task(); // might throw

do_another_task(); // might throw

} catch (const std::exception& e) {

std::cerr << e.what () << std::endl;

}

}

If any exception is thrown there are two possible sources for that error. The more complex those functions are the more difficult it becomes to locate the errant code. Indeed, the error could originate from a deeply-nested series of function calls from within either of these two functions.

However, it is not actually necessary to know where an error occurs in order to handle the error. It is enough to know that the error has been caught. It's the ones we don't catch that we really need to worry about because an unhandled exception will terminate our program without any warning. Worse, whatever message the exception carried with it will be lost forever (we'd need to use a debugger to determine why the program aborted).

Production code will often place a series of specific exception handlers in main(), along with a somewhat convoluted catch-all to try and catch any and all unknown exception types:

int main () {

try {

do_a_task(); // might throw

do_another_task(); // might throw

} catch (const int& i) {

std::cerr << i << " : some idiot threw an integer!" << std::endl;

} catch (const char* s) {

std::cerr << s << std::endl;

} catch (const std::string& s) {

std::cerr << s << std::endl;

} catch (...) {

std::exception_ptr eptr {std::current_exception()};

try {

if (eptr) std::rethrow_exception (eptr);

} catch (const std::exception& e) {

std::cerr << e.what () << std::endl;

} catch (...) {

std::cerr << "unknown exception type" << std::endl;

}

}

Note that catch (...) is the catch-all handler but even this cannot be guaranteed to catch all errors, particularly if we make extensive use of third-party libraries. Programmers that throw meaningless integers instead of well-defined exception classes derived from std::exception are a particular annoyance, because two different libraries might use the same integer value to represent two completely different exceptions. Then there are those who persist in throwing C-style strings or (worse) std::string objects. Then there are those who detest the standard library to such a degree they will re-invent the wheel and throw ad-hoc exception classes into the mix.

Some implementations may provide proprietary methods that will catch any and all exceptions, however the code is not portable.


Some exceptions simply cannot be caught because they are not exceptional. Division by zero is a common example. This is not an exception because any code that allows a divide by zero operation has undefined behaviour. As such, the entire program is invalid and no amount of exception handling will turn an invalid program into a valid one. Note that division is a low-level machine operation, not a high-level function. The only way to prevent a divide by zero error is to not do it. Always check your denominators are non-zero! This is no different to ensuring a pointer is non-null before attempting to dereference it. But if you use smart pointers instead of "naked" pointers you get automatically get all the benefits of exception handling at no cost. Indeed, the fewer runtime tests you perform the more efficient your code will be.