I'm trying to understand error handling in C++.
I have read that using try, throw, catch is better style and less complicated than using if statements with return values. But I'm not sure I really understand how try, throw, catch works. I made a simple example below and it would be great to get feedback about any problems or bad style. My goal is to make a function out of the example that checks the results of another calculation.
Here are questions I have about try, throw, catch:
(1) Should the catch statement be included in my function? Or should it be somewhere else, like in main() or in the function where the initial calculation is done?
(2) Is it overkill to use try, catch, throw for something this simple (I would like to improve my style)?
(3) If there is an error, I would like to terminate the program. How would I do that? Or does "catch" mean that that is done automatically?
(4) I don't understand the use of cerr. Why not just use cout? Have I used cerr correctly here? Should I also have used it in the if/else statements?
Thanks a lot for any help.
Here's the example I made:
double calculated = 10.2; // from previous calculation
double tolerance = 0.3; // I can set this in this function
double valueWanted = 10.0; // from previous calculation
const int calcError = 5; // I picked this number randomly to use for indicating an error
try
{
if (fabs(fTargetValue - fCalculated) <= fTolerance)
cout << "Result is within range.";
else
cout << "Failed.";
throw calcError;
}
catch (const int calcError)
{
cerr << "The calculation failed.\n" << endl;
}
Well that's a lot of questions. I will try to give you some hints :
(1) Do not include the try-catch in your function. Throwing an exception is done to tell the outer world that something happened. If you can handle the problem in your function, do not throw at all ^^ A good error handling is generally to catch the error ASAP (in the caller) or in a general purpose handler far away like in main, to handle gracefully unhandled errors.
(2) As a rule of thumb, use exception for ... exceptional things. Errors are good candidate for exceptional things. An exception could be thrown for things like overflow or division by zero in a math library. You have to decide, but in general it is good to handle errors with exceptions.
(3) catch do not mean that your program will end. In fact it is the contrary. By catching an exception, you say that you will handle the problem ^^ If you want to terminate, a simple way in a simple program is to not catch exception, as the default behavior for uncaught exception is program termination ^^ Instead, you can explicitly terminate your program in some catch block.
(4) cerr is just like cout, but is a different file descriptor. It means that external programs can differentiate cerr from cout. It is used for error, but that's not really important but for external programs.
my2c
Ok, firstly your example will throw every time because you do not have scope braces after the else. Therefore, only cout << "Failed."; will be executed and throw calcError will be executed each time, regardless of whether the result was in range or not. Change this to:
else
{
cout << "Failed.";
throw calcError;
}
In the event that an exception is throw, the code will begin within the catch block you have defined, stating the calculation failed.
If the result was in range (throw is never called), code will begin executed directly after your catch block.
When you throw a type, that type arrives at the catch handler. This allows you to define catch handlers for different types. In this case, you are throwing (and catching) a const int. That's all good. Generally, we throw std::exception or a derivation of this. Your own exception classes can contain information pertinent to the error. In your case you could include a simple message that it was out of range, or indeed include the const int that failed.
The catch statement should be in the first function up from the one that throws (maybe in the function that throws) that can recover from the exception and allow the program to continue normally.
Yes, there's no point throwing really if you expect to be catching it. Also, your normal program flow shouldn't throw. As a rule of thumb, only throw for when you get into a situation you don't really expect should ever happen. Exceptions are called exceptions because they happen in exceptional circumstances. Often a good time to use exceptions is when interacting with the programs environment. You usually expect certain things to work, eg to be able to allocate memory, open a file, receive a complete data packet from a network device etc. All these cases should result in an exception being thrown. Also, if your program receives input, it should initially validate it. But, later on, during processing, if there's something wrong with the data that should already have been rejected by the validation, such as a divide by zero occurring because of strange input data, that would also be an exceptional situation. IF you rely on exceptions too much for when expected things happen, the flow and logic of your program can become overly difficult to reason about and the program maintenance gets unnecessarily hard.
If there is an error, just don't catch. If there's no catch, the exception will go all the way up to your main function, and will then go to the runtime from there which will terminate your program. And, for some O.S.s such as windows this will cause a minidump file to be created which you could use to debug your program with to find out what exception caused it to terminate.
cerr and cout just give you two ways of outputting information from your program. In cases where another program consumes the output of your program to do something, it will read cout and expect to understand it. This means if you want to write out errors or warning that the consuming program won't understand you have to write them to cerr so that you don't confuse the second program that's reading your programs normal cout output.
The C++ standard has a few exception classes that are all derivable from. I suggest you do that instead of throwing and catching PODs. It's not hard, either, and would improve (and specify the type of error) like so
class CalculationError : std::invalid_argument
{
public:
CalculationError(std::string const& msg)
: std::invalid_argument(msg)
{}
};
For a quick overview of the exception hierarchy go to http://www.richelbilderbeek.nl/CppExceptionHierarchy.htm
The problem is: when you throw a POD type, there is no attached message. The great part about throwing exceptions is the ability to write out a message about what might have gone wrong, and how to fix it. This is not possible when throwing an int.
There are three output streams in C++: log, cerr, and cout. Each of them are represented differently, which means that, when starting your program, you can use the command line to filter out each of these streams. This is great for debugging then, as you can filter by cerr and see if your program failed a test.
Example: my_program > out.txt 2> log.txt (cout goes to out.txt, the others to log.txt)
However, I would recommend not just cerring. Usually, the point of a catch is to reverse program state! If you, for example, tried to allocate a dynamic array, and that fails, the catch would be responsible for destructing the array again before rethrowing. Otherwise, you would have a whole bunch of things like memory leaks and whatnot.
What's also important to note is that, once caught, the exception is "swallowed". If you cannot or do not want to deal with the error here, it is best to write
catch(/* Error to be caught */)
{
throw; // Rethrows original exception, propagating it upwards
}
If you want some good literature about this, Herb Sutter wrote a book called Exceptional C++ and it covers exception safety in a practical and enlightening way (imo). It's definitely worth checking out if you want to know when and why you need to throw exceptions.
Hope this helps!
Did not you forget a block around the else case
try
{
if (fabs(fTargetValue - fCalculated) <= fTolerance)
cout << "Result is within range.";
else {
cout << "Failed.";
throw calcError;
}
}
There are lots of good answers here for your questions. I was just reading about cerr and I would like to share what I was reading here. The source is "C++ Basic Structures: Vectors, Pointers, Strings, and Files" course in Coursera platform.
Here is the quote:
"When printing error messages, cerr is preferred over cout. cerr is not bufferred, which means it is not stored in memory to be printed later on. It just gets printed immediately. Therefore, as a rule of thumb, important data and variables should be printed with cout while error messages should be printed with cerr."
Also:
"cerr is an unbuffered output stream. This means that the output is immediately printed and not stored for later. This makes cerr more suitable for use with error messages where its storage is not important.
On the other hand, cout is buffered, meaning its output is temporary stored so that the system can retrieve it later for quicker access. cout is more suitable for important data and variables that are used throughout the program."
Related
When we declare a std::vector, or std::string, ..., like that for example
std::string hello("Hello");
isn't it wrong? shouldn't we do
std::string hello;
try {
hello = "Hello";
} catch (std::exception &e) {
std::cout << e.what() << std::endl;
return (-1);
}
Because if I understood how it works, when an allocation fails, it will result in an uncaught exception otherwise, so why do I often see code like this ? :
std::string s("hello");
s += " world";
s += "!";
s.reserve(100);
...
without any check?
Allocation failure is rarely checked because there is rarely a reasonable way to recover from it. What should the program do when there is no memory to do what the program needs to do? Usually, the only reasonable response is to stop what you're doing, which is exactly what happens when you don't catch the exception.
Furthermore, some language implementations don't necessarily even fail to allocate since they may over allocate memory. Such system will delay actual allocation until when the memory is actually accessed. As such, even if you did have a clever strategy to handle lack of memory, you cannot rely on allocation failure to detect such case, unless you know that the target system doesn't over allocate.
Most people know how memory-intensive their app is, but what are you going to do if you can't allocate a string? You probably also at that point can't do much of anything, and you're going to have to exit.
When you have actual recovery you can do, people will probably catch all exceptions at a higher level -- several method calls back, and then do what they can. Hopefully by rolling back the stack a bit, you'll release enough resources you can do whatever error handling you'd like before exiting.
The prize question is: what do you do if you catch such an error? Unless you've got some special circumstance where you are able to recover from such an error, there is simply no point in catching it. Even in your example you simply return an error code - basically doing what the exception would have done for you otherwise, which is their entire point. You're probably just more comfortable with error returns than exceptions, which is why you prefer that scenario.
If such an exception is thrown, the next step is almost always to fail the routine that encountered it. Doing so by letting the exception bubble up is the best, least verbose way to do that. If you want to prevent crashes, add a try-catch at the entry function of whatever thread you're in, which prints the exception and exits gracefully. But, especially for debugging/testing, that often just hides useful information without providing much benefit. I prefer only catching specific errors that I can recover from in some way.
It's a pain to wrap everything that can throw an exception in try/catch.
Unless you anticipate the failure and know how to recover from it, most often you don't. Memory allocation errors like this are hard to recover from. If you don't catch the exception yourself, the stack will unwind all the way to the program's entry point and e.what() will be printed before the program aborts.
I am reading literature on "C++ Exception Handling" (EH) from various resources. I have understood the concepts as well as the syntax. BUT On a larger scale I am confused .
We write code to execute it completely. It is expected that the written code will execute in known specific way(s). If some part of code throws exception and it is handled and the program continues execution. But from throw point to catch function some function(s) did not execute,normally they should have been, then how come the program can continue further as it is not completely executed.
I have come across statements that tells EH is used for error recovery.
But i need some concrete example to see what error recovery means / how it is done especially in C++ EH.
When an exception is thrown, execution does not continue from the point immediately after where the exception was thrown. Rather, execution is transferred back to the "nearest"1 catch block that can catch the type of exception that was thrown. After the code in that catch block executes, execution continues in whatever code comes after it, just like usual. That might (eventually) lead back to the code where the exception was thrown, but 1) doesn't necessarily, and 2) if it does, re-runs the code leading up to that point, so if the exception isn't thrown (for whatever reason) the following code can be expected to execute normally (presuming, of course, that the other code is exception safe, so nothing has gotten mucked up in the process).
It's difficult to find good examples of error handling using exceptions (or otherwise, TBH), largely for some of the same reasons for using EH to start with -- the code to handle the exception properly is often (usually?) quite specific to the application at hand. For some small utilities and such, it may just print out an error message and exit. For a server that needs to keep running regardless of what happens, it might write something to the log, then continue executing.
Here "nearest" has nothing to do with location in the source code -- it's based on execution. When code in a try block is executed, the corresponding catch block is set up stack-style. When an exception is thrown, the stack is unwound until it reaches a catch block that can handle the exception that was thrown.
Exceptions are safety nets, but they aren't meant to handle programmer errors (i.e. segfaults)
For example, let's say you're trying to read a file on disk that hasn't been written yet, but you know it will be at some point. Would you want to crash and burn the entire process? Probably not.
If you caught some sort of exception that indicated the file wasn't there yet, you could handle it appropriately by retrying at a later time, or logging some sort of a message.
Note EH = Exception handling
We do EH to make sure that we do not get run time abnormal behavior of program, which can be due to some unexpected input/data at any point of execution or data corruption in processing. It depends on developer how he handles exception(s) i.e show any error message or correct the data and continue.
for example
class PlayGame{
private:
/* variable */
public:
bool inputUserName() throw(){
**** if user do not enter name throw exception
}
void play(){
********
}
void end(){
****
}
};
void game() throw(){
PlayGame pg;
pg.inputUserName();
pg.play();
pg.end();
}
void main(){
/* one way of work */
try{
game()
}catch (exception& e){
cout<<"Error occour.. user name missing..\n";
}
/* second way can be */
try{
game();
}catch (exception& e){
cout<<"Please enter name first...\n";
game();
}
}
This is good example of understanding EH in c++
Maybe the concept of "strong exception safety" provides somewhat an answer to both of your questions. A function which is strongly exception safe will either complete regularily or, if throwing, leave the state of the program as it was before it was called.
Disregarding for the moment if that can be achieved, let's assume your code is composed of strongly exception safe functions:
Obviously execution can continue whenever an exception is caught. Just catch it at a point where there is an alternative route for execution. Ultimately just not executing the program at all. Of course you must admit failure to execute as a possibility. However, anything else would be perfection and somewhat unrealistic.
I recommend Herb Sutter's "Exceptional C++" books (see http://www.gotw.ca/publications/xc++s.htm) or his Guru-of-the-Week postings, e.g. http://www.gotw.ca/gotw/059.htm
In general "error recovery" here means rolling back any changes. This usually can only be achieved by doing everything tentatively, eg. on a copy, until success is ensured.
Above that, error recovery is an architectural issue of designing your program with lots of places, where alternative executions routes exist.
My understanding of the try function, was to stop errors that could possibly occur between try and catch.
But if I do something like this:
std::vector<int> testvector;
testvector.push_back(1);
try{
cout << testvector[53485375345534] << endl;
}catch(...){
}
My idea was that it would not cause an error in the expense for memory, but it does nothing in this case, an error still pops up.
Could someone explain the proper reason for using try, so far in my experience, i could have used an if statement beforehand instead, could someone give me an example when you would need a try statement?
operator [] does not check for bounds in std::vector.
However, std::vector::at() does throw an exception. You should use it instead.
There are different kinds of errors:
Exceptions. These are the errors your program creates, throws and that you can catch and handle.
Access violations, system exceptions and so on, aka "crashes". These are very severe, you can't do much when they occur (at least not inside standard C++'s possibilities), so it's best to write correct programs then these wont crop up.
Assertions. These are meant to check your program logic and constraints during development and testing. They normally appear only in debug code, i.e. they should be turned off in release builds. If an assertion occurs, in Windows a window pops up saying what went wrong.
I am only guessing here - are you using MS Visual Studio?
MSVC's vector implementation checks the operator[]'s argument in debug mode and asserts if the argument indeed is within the vector's range. That assertion is not an exception, so you can't catch it.
Your test case is invalid, std::vector::operator[] doesn't do boundry check, also it doesn't throw exception, you are expecting undefined behavior instead of exception. You could try std::vector::at function
std::vector<int> testvector;
testvector.push_back(1);
try{
std::cout << testvector.at(53485375345534) << endl;
}catch(std::exception& e){
std::cout << e.what() << std::endl;
}
The concept of Try-Catch is about handlings errors which could break your program but most often could be handled without doing so.
Your example is a good one for an operation which is totally correct but only if the data you are requesting exists. That "only if" could be handles by the function itself but then you could never react to the faulty input. Instead the function throws in such cases an exception which can be handle by your code if you surround the calling with a Try-Catch.
Within the Catch block it is often appreciated that you inform the user or at least write the missbehavior to a logfile and you could also load default values or even alter the variables and repeat the function call.
Sometimes the Try-Catch is described as "Ask for forgiveness not for permission" (the latter would be a prior If).
In general the Try-Catch can be read in pseudocode as:
Try:
Do what you think is right to do but be aware it could be wrong...
Catch:
You were too optimistic and should react in a proper way...
I hope that helps to understand the Try-Catch concept a bit better.
When you are using some functions that you are not sure they are going to work, you'll use a throw statement. For example you want to make a GUI windows, you'll use a try block, so in case windows wasn't created, you'll not end up waiting for inputs on a windows that doesn't exist.
I mean, I knew all the language rules about throw, try {} catch {}, but I am not sure if I am using them correctly in the real world. Please see the following example:
We have a large piece of scientific code which did all sorts of image processing things, recently we decided to spruce it up and make it more robust. One of the routines which is frequently used is void rotate_in_place(float* image, image_size sz);
To make it more robust, we add some sanity check at the beginning of the code:
void rotate_in_place(float* image, image_size sz) {
// rotate_in_place does not support non-square image;
if (sz.nx != sz.ny) throw NonSquareImageError;
// rotate_in_place does not support image too small or too large
if (sz.nx <= 2 || sz.nx > 1024) throw WrongImageSizeError;
// Real rode here
.....
}
Now the problem is that rotate_in_place() is used in over 1000 places, shall I wrap each call of rotate_in_place() with try{} catch {}, this looks to me will make code incredibly bloated. Another possibility is do not wrap any try{} catch{} and let the program exit, but how is this different from just using
if (sz.nx != sz.ny) {
cerr << "Error: non-squared image error!\n";
exit(0);
}
In short, I am not so sure about the real benefit of using throw, try, catch, any good suggestions?
Every site that handles the error needs try-catch block. It all depends on your design, but I doubt you need to handle the error in every rotate_in_place call-site, you probably get away from propagating upwards most of the time.
Printing the error and using exit is bad for three reasons:
You can't handle the error. exit is not handling (unless it's done when the error is absolutely critical, but your function cannot know that — caller might have a way to recover).
You're extending responsibilities of the function with writing to a hard-coded stream, which might not even be available (this is rotate_in_place, not rotate_in_place_and_print_errors_and_kill_the_program_if_something_is_wrong) — this hurts reusability.
You lose all debugging information with this approach (you can generate stack traces from unhandled exceptions, you can't do anything with a function that bails out every time — unhandled exception is a bug, but it's a bug you can follow to the source).
The general rule for exceptions is, "Does the immediate call site care about what's going on here?" If the call site does care, then returning a status code probably makes sense. Otherwise, throwing makes more sense.
Consider it this way -- sure, your rotate in place method has a couple of invalid argument types, in which case you should probably throw std::invalid_argument. It's unlikely that a caller of rotate_in_place wants to deal with or knows how to deal with the case that an image was not square, for example, and therefore that's probably better expressed as an exception.
Another possibility is do not wrap any try{} catch{} and let the
program exit, but how is this different from just using
if (sz.nx != sz.ny) {
cerr << "Error: non-squared image error!\n";
exit(0);
}
It's different because if someone later wants to take your function and put it in, say, a GUI application, they don't have to terminate the program based on the error. They can turn that exception into something pretty for the user or something like that.
It also has benefits for you right now -- namely that you don't have to pull <iostream> into that translation unit simply to do error writing.
I usually use a pattern something like this:
int realEntryPoint()
{
//Program goes here
}
int main()
{
//Allow the debugger to get the exception if this is a debug binary
#ifdef NDEBUG
try
#endif
{
return realEntryPoint();
}
#ifdef NDEBUG
catch (std::exception& ex)
{
std::cerr << "An exception was thrown: " << ex.what() << std::endl;
}
#endif
}
Now the problem is that rotate_in_place() is used in over 1000 places, shall I wrap each call of rotate_in_place() with try{} catch {}, this looks to me will make code incredibly bloated.
It will, and it beats the purpose of using exceptions in the first place.
Another possibility is do not wrap any try{} catch{} and let the program exit, but how is this different from just using [...]
That you can always change the location of exception handling later on. If at some point you find a better place to sensibly handle the error (perhaps recovering from it), then that's the point where you put the catch. Sometimes that's in the very function where you throw the exception; sometimes it's way up in the call chain.
Do put a catch-all in main, just in case. Deriving exceptions from standard ones such as std::runtime_error makes doing this a lot easier.
The point in using exception handling holds in following simple rules:
As soon as anything bad can happen due to bad user input (internal logic should be handled via assertions/logging), throw an exception. Throw as soon as possible, and as much as possible: C++ exceptions are usually pretty cheap compared to say, .Net ones.
Let an exception propagate if you can't handle the error. This means pretty much always.
The thing to remember is: The exception should bubble up to the point where it can be handled. This can mean a dialog box with some formatting of the error, or this can imply that some unimportant piece of logic won't be executed after all, etc.
Using exceptions allows the caller to decide how to handle an error. If you called exit directly within the function, then the program would exit without the caller being able to decide how to handle the error. Also, with exit, stack objects would not be unwound. :-(
What you can do is to make rotate_in_place return a boolean if the function call was succesfull. And return the rotated image via a function parameter.
bool rotate_in_place(float* image, image_size sz, float** rotated_image) {
// rotate_in_place does not support non-square image;
if (sz.nx != sz.ny) return false;
// rotate_in_place does not support image too small or too large
if (sz.nx <= 2 || sz.nx > 1024) return false;
// Real rode here
.....
return true;
}
It depends.
Exceptions are generally meant to be caught/handled. In your case, is it possible to handle the exception (for instance, the user provides a non-square image, so you ask them to try again). However if there is nothing you can do about it, then cerr is the way to go.
Well, I agree that really using Exceptions results in bloated code. That is the main reason for me not liking them.
Anyway, as to your example: The key difference between throwing exceptions and just using exit() is that, since the handling of the exception happens (or is supposed to happen) outside of the program fragment that generated the error/exception, you do not specify how the user of a function/class has to handle the error. By using exceptions you allow different treatments like aborting the program, reporting errors or even recovering from certain errors.
TLDNR: If you use exceptions, the exception-generating part of the code does not need to specify how the exceptional case is treated. That happens in the outside program and can be changed depending on how the code is being used.
Each time I have seen the catch all statement:
try
{
// some code
}
catch (...)
{
}
it has always been an abuse.
The arguments against using cache all clauses are obvious. It will catch anything including OS generated exceptions such as access violations.
Since the exception handler can't know what it's dealing with, in most cases the exceptions will manifest as obscure log messages or some incoherent message box.
So catch(...) seems inherently evil.
But it is still implemented in C++ and other languages (Java, C#) implements similar mechanisms. So is there some cases when its usage is justified?
(1) It's not true that the statement will catch OS exceptions. Your use of the term "Access Violation" betrays a Windows background; it was true for older MSVC++ versions.
(2) Regardsless, the catch-all behavior is useful for threads with specific purposes. Catching the failure allows the thread to report it failed. Without it, the other parts of the program need to deal with the possibility of a thread just disappearing. It also allows you to log which thread failed, and the arguments used to start the thread.
The case where it's justified in general is when you log the exception (or do something similar) or do some cleanup, and then immediately rethrow.
In C++ in particular, logging in a catch(...) block is pretty pointless since you don't have any way to obtain the exception, and cleanup is pointless because you should be using RAII for that. Using it in destructors seems to be about the only legitimate case.
the arguments against using cache all clauses are obvious , it will catch anything including OS generated exceptions such as access violation. since the exception handler can't know what its dealing with, in most cases the exceptions will manifest as obscure log message or some incoherent message box.
And if those same exceptions aren't caught you get... an incoherent message box.
catch(...) lets me at least present my own message box (and invoke custom logging, save a crash dump, etc.).
I think there are also reasonable uses of catch(...) in destructors. Destructors can't throw--well, I mean, they can throw, but if a destructor throws during stack unwinding due to an in-progress exception the program terminates, so they should not ever allow exceptions to escape. It is in general better to allow the first exception to continue to be unwound than to terminate the program.
Another situation is in a worker thread that can run arbitrary functions; generally you don't want an unceremonious crash if the task throws an exception. A catch(...) in the worker thread provides the opportunity for semi-orderly clean-up and shutdown.
In addition to what other posters have already said, I'd like to mention one nice point from the C++ Standard:
If no matching handler is found in a
program, the function std::terminate()
is called; whether or not the stack is
unwound before this call to
std::terminate() is
implementation-defined.
(15.3/9)
This means that main() and every thread function must be wrapped in a catch-all handler; otherwise, one can't even be sure that destructors for automatic objects will be called if an uncaught exception is thrown.
try {...} catch (...) is needed around body of callback function which is called from code
that doesn't understand C++ exceptions (usually C library).
Otherwise, if some C++ library you use throws an exception that doesn't derive from
std::exception, it will probably cause calling code to crash or corrupt its internal state.
Instead you should catch this exception and either finish program immediately or
return some error code (meaning "we are doomed and I don't know why", but it's still better
then letting C++ exception to pass through).
Around thread procedure. Mostly because of the same reason as 1.
And because otherwise thread failure would pass unnoticed.
catch(...) has been useful for me in two circumstances, both of which are unjustified (I can't even remember the second)
The first is my overall application safety. While throwing exceptions that don't derive from std::exception is a No-No, I have one just in case in my main() function:
int execute(void); // real program lies here
int main(void)
{
try
{
return execute();
}
catch(const std::exception& e)
{
// or similar
std::cerr << "Unhandled exception: " << e.what() << std::endl;
return EXIT_FAILURE;
}
catch(...)
{
std::cerr << "Unknown exception!" << std::endl;
return EXIT_FAILURE;
}
}
Now, it's only there "just in case", and it's not really justified. There should be no reason to ever enter that catch clause, as that would mean somebody has done a Bad Thing. Observe how useless the statement really is; "Something bad happened, no clue what!" It's only a step above just crashing in the first place.
The second use might be in destructors or some other function that needs to do manual management before letting the exception propagate. That's not really a justification either, as things should clean themselves up safely with RAII. But I may have used it once or twice for some reason I can't recall, and I can't see a reason to ever do so again.
catch (...) allows you to write code in which you can legitimately claim a guarantee that your code will not crash even when you are not in long term complete control of the submodules your code depends on. Your claim is tantamount to claiming that this semantic cannot be used except as a means of abuse. Maybe so, but military specifications may differ from you on this issue.
catch(...) is necessary in the absence of the finally clause as found in other languages:
try {
...
} catch(...) {
cleanup...
throw;
}
The alternative - making stack objects to 'own' everything - is often much more code and less readable and maintainable. The platform API is often C, and does not come with it conveniently bundled.
It is also useful around plugin code that you do not control or simply do not trust from a stability perspective. It won't stop them crashing, but it might keep things a little saner.
Finally, there are times when you really do not care about the outcome of something.