Thread: Error Handling in Constructor

Originally Posted by dwks

No, you should just use containers that do the allocating for you.

Like vectors and strings, as Daved pointed out? But isn't that pretty much refraining from using new/delete directly?

Originally Posted by Hikaru

I think that if you do it right, there won't be many try/catch statements so checking return values is the one that clutters your code..

I disagree. Using try/catch blocks remove your focus from the actual flow of your program and you could end up with several such blocks for every single thing you do as you would need to clean up your traces in the correct order. Anyway, that's not the point of this post

Originally Posted by Halloko

I disagree. Using try/catch blocks remove your focus from the actual flow of your program and you could end up with several such blocks for every single thing you do as you would need to clean up your traces in the correct order. Anyway, that's not the point of this post

If you are finding yourself needing to clean up using try..catch repeatedly, chances are you should be using containers for your pointers, which will automatically do the cleanup in their destructors.

The beauty of exceptions is a single try...catch could deal with, say, thirty possible error conditions. You do need to write your code to not leak memory in the event of an exception, but it's not hard to make cleanup code happen in destructors (which means -- automatically).

Originally Posted by Cat

If you are finding yourself needing to clean up using try..catch repeatedly, chances are you should be using containers for your pointers, which will automatically do the cleanup in their destructors.

The beauty of exceptions is a single try...catch could deal with, say, thirty possible error conditions. You do need to write your code to not leak memory in the event of an exception, but it's not hard to make cleanup code happen in destructors (which means -- automatically).

I guess you have a point. It does also mean, however, that you need to wrap every single C-style API you want to use instead of just going for plain error-checking.

As mentioned earlier, I think the way to go is to use the best of both worlds really.

Originally Posted by Halloko

I guess you have a point. It does also mean, however, that you need to wrap every single C-style API you want to use instead of just going for plain error-checking.

You don't need to do much, you just do:

if (C_Style_Function() == ERROR_CONDITION)
throw std::runtime_error("C_Style_Function failed!");

The only things you wrap are things that require special cleanup. For example, you'd wrap a SOCKET because if you open it, you need to close it (i.e. special cleanup).

Originally Posted by Cat

You don't need to do much, you just do:

if (C_Style_Function() == ERROR_CONDITION)
throw std::runtime_error("C_Style_Function failed!");

But if you are checking the return values anyway, why not just handle the error locally instead of throwing an exception which is caught in a catch-statement further down?

Am I missing the point here?

Originally Posted by Halloko

But if you are checking the return values anyway, why not just handle the error locally instead of throwing an exception which is caught in a catch-statement further down?

Am I missing the point here?

Because, in general, you're duplicating a whole lot of code. You typically would:
1. Cleanup (actually not needed if you're coding smart and letting everything clean itself).
2. Report the error to the user
3. Make a choice to continue/abort the program

In general, there will often be 10-20 different error checks that require the same prompt (maybe a different string displayed) and the same choice. In general, there are often a whole series of error checks which result in using the same exact code to recover. For example, any failure to open and read a file, whatever caused it, is probably recovered by informing the user, then using blank/default data, or possibly terminating the program if normal operation cannot continue without that file.

Exceptions provide a way to do this fast, and also to force users to error check -- the program cannot continue if there
is an error that isn't handled. If you forget to check a return code, the program continues with the error uncaught.

Exceptions also make it easier to propagate an error up a chain of function calls (which is your other option to reduce the amount of code duplication). You only do the error-checking on the deepest call; the others just transparently propagate the error through. Without that, you need to do a check on each level.