Error Handling in Constructor

[Halloko]

Hey,

Over the past few weeks I've experienced the same dilemma during coding:

If you want to use the constructor to initialize some class member variables (such as allocating memory), what is the best practice approach to deal with errors?

I prefer not working with exceptions in my code so I started wondering how one tells the caller that the initialization failed in the constructor. I guess the obvious solution would be to not perform any operations that could potentially fail in the constructor, but this would just lead to extra code when initializing the class:

// Allocate 1024 bytes of memory
CFoo foo(1024);

OR

CFoo foo;
if (!foo.Allocate(1024))
     ...

OR

CFoo foo(1024);
if (foo.InitFailed())
     ...

As is evident from the code snippet above, the second example requires two lines of code compared to a single line in the first example. The last example is just a slight variation on the second example, although the initialization now takes place in the constructor whereas the success of the initialization is verified later on in the second function call.

When not using exceptions I guess there is no alternative to doing multiple function calls if you want to make sure the object was created and initialized successfully. The question, however, is which approach is the best to use...

[Hikaru]

If you want to use the constructor to initialize some class member variables (such as allocating memory), what is the best practice approach to deal with errors?

I can only think of two ways. First, you can throw an exception. Or you can set a flag or something that code using the class can test for. fstreams use the flag, and I can't think of a C++ class that throws an exception so a flag sounds like the best way.

#include <fstream>
#include <iostream>

int main()
{
    std::ifstream is("myFile.txt");

    if (!is)
    {
        std::cerr << "File not open!\n";
    }

    return 0;
}

[Daved]

There is an in-depth discussion about exceptions versus error flags currently going on in the Classes and error handling thread.

I would re-consider the use of exceptions. If you don't use exceptions, I would prefer to use option #3, since if the class user forgets to call the second function, the code will still work when the initialization worked. In either scenario, a failure to call the second function will be an error if the initialization is going to fail.

Also, in C++ you rarely actually need to do allocations directly in the constructors of your objects. You should be using tools that handle memory management for you (like string or vector). In those cases you will be forced to use exceptions for memory issues unless you specifically force new to not throw an exception when it fails.

[Halloko]

I would re-consider the use of exceptions.

I'm a bit old-fashioned (or whatever you'd like to call it). I prefer actually checking return values rather than cluttering my code with try/catch statements.

If you don't use exceptions, I would prefer to use option #3, since if the class user forgets to call the second function, the code will still work when the initialization worked. In either scenario, a failure to call the second function will be an error if the initialization is going to fail.

I completely agree.

Also, in C++ you rarely actually need to do allocations directly in the constructors of your objects. You should be using tools that handle memory management for you (like string or vector).

So you're saying that I should refrain from using new/delete?

In those cases you will be forced to use exceptions for memory issues unless you specifically force new to not throw an exception when it fails.

That leads to an interesting question (for my part). What happens if you force new to not throw an exception when it fails? Does it just return NULL?

[dwks]

So you're saying that I should refrain from using new/delete?

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

That leads to an interesting question (for my part). What happens if you force new to not throw an exception when it fails? Does it just return NULL?

Yes.

[Hikaru]

I prefer actually checking return values rather than cluttering my code with try/catch statements.

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.

What happens if you force new to not throw an exception when it fails? Does it just return NULL?

It looks like it.

[King Mir]

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

If you don't want exeptions you would need to specify your own allocator though.

[Daved]

>> I prefer actually checking return values rather than cluttering my code with try/catch statements.
Using exceptions well generally means there aren't a lot of try/catch blocks. They are for exceptional situations (e.g. out of memory) and should only be caught in places that can do something about it or terminate gracefully. It's obviously your choice, but in this situation, assuming the errors you are worried about are like out of memory errors, the code with exceptions (option #1) is a lot less cluttered than the one without.

If you're talking about more common errors (like a file open failure), then exceptions might not be the way to go.

>> So you're saying that I should refrain from using new/delete?
It depends, but in most circumstances, yes. If you are "old-fashioned" then it might take some getting used to, but modern C++ has a lot of tools that handle these things for you so you don't have to put all the error checking and memory management into your own code and you don't accidentally do it wrong.

[Mario F.]

I'm a bit old-fashioned (or whatever you'd like to call it). I prefer actually checking return values rather than cluttering my code with try/catch statements.

This is not a good argument. You don't simply pick as if you were in a supermarket choosing oranges by color and size. It's not a matter of taste. It's a matter of good practice and code correctness.

While it may be debatable whether one should use exceptions here or there, the reason is never because "I don't like them" or "I'm old fashioned". Adapt, or fail.

It's that simple.

[Cat]

I'm a bit old-fashioned (or whatever you'd like to call it). I prefer actually checking return values rather than cluttering my code with try/catch statements.

In general, you need far fewer try...catch statements than you do error-checking lines.

In fact, that's the best reason in favor of using try...catch, you can often get a massive reduction in the amount of code you need to write to handle errors.

[Halloko]

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?

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

[dwks]

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

Yeah, I guess it is.

[Cat]

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).

[Halloko]

>> I prefer actually checking return values rather than cluttering my code with try/catch statements.
Using exceptions well generally means there aren't a lot of try/catch blocks. They are for exceptional situations (e.g. out of memory) and should only be caught in places that can do something about it or terminate gracefully. It's obviously your choice, but in this situation, assuming the errors you are worried about are like out of memory errors, the code with exceptions (option #1) is a lot less cluttered than the one without.

If you're talking about more common errors (like a file open failure), then exceptions might not be the way to go.

Yes, I was talking about using exceptions for everything. And I definitely agree that a mixed approach is the way to go. For this particular case, using exceptions definitely seems to be the less cluttered choice.

>> So you're saying that I should refrain from using new/delete?
It depends, but in most circumstances, yes. If you are "old-fashioned" then it might take some getting used to, but modern C++ has a lot of tools that handle these things for you so you don't have to put all the error checking and memory management into your own code and you don't accidentally do it wrong.

Hmm, I'd definitely want to have a peek at that. I've always just used new and delete.

[Halloko]

This is not a good argument. You don't simply pick as if you were in a supermarket choosing oranges by color and size. It's not a matter of taste. It's a matter of good practice and code correctness.

While it may be debatable whether one should use exceptions here or there, the reason is never because "I don't like them" or "I'm old fashioned". Adapt, or fail.

That wasn't really what I meant by "old-fashioned". I merely meant that I did things the c-style way, that is, not using exceptions when I could avoid it.

As has become evident in this thread, for this particular question using exceptions is the way to go. But as you say yourself, when to use exceptions and not is debatable, but I've found that using c-style error checking rather than exceptions for most common cases such as file handling is the best approach.. for me.