Question

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?

Answer 1

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:

1. 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).
2. 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.
3. 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).