Thread: Exception safe constructor/destructor

Originally Posted by TriKri

So...

How do you then create an object of a class which constructors throw exceptions? According to what you say, the object doesn't exist, so you can't use it. In other words, code trying to use it will produce compile time errors?

If the constructor throws, then the object will never exist, so you cannot use it.
However, note that if the constructor can throw, but it does not, since no error was encountered, then you can use the object.
Essentially you would just use it as normally below where you created it, inside the try blocks and before the catch blocks, if any.

Maybe exceptions are not supposed to be used as often as I have thought. Since an exception always breaks the scope, you cannot use an object if it's constructors throws exceptions. Consider the following scenario:

Code:

void MyFn() {
    MyClass MyObj();
    ... //A lot of code that may use MyObj, depending on the result of the constructor call
}

Now, if the default constructor can throw an exception, you would have to wrap it in a try block:

Code:

void MyFn() {
    try {
        MyClass MyObj();
        ... //A lot of code that uses MyObj
    }
    catch (ExceptionType exception) {
        ... //A lot of more code (doesn't use MyObj)
    }
}

What happens here is that we will have to write the code two times. One time in the try block (since we want to use MyObj before it goes out of scope), and one time outside of the try block (since we still want to run the code if the constructor fails). The amount of code will almost double.

So my thought was that, if you for example want the thing that caused the exception to be acceptable (i.e. you want the program flow to continue in spite of it, and that not everything just bailes out), maybe you shouldn't use an exception. Maybe one should use some other method instead, like indicating in some way the result of the constructor call (typically a flag would be used), rather than having to leave the scope due to an exception.

What are your thoughts about this?

I also assume that if the constructor throws, the object will never have existed, hence the destructor won't be called.

Essentially, yes, I think you have a point in what you say.
Exceptions are good if you have a large block of code that depends on the former lines to execute without problems.
If not, then you might consider return types.

You could pass in a status variable, eg a bool to the constructor which will set it to false or true depending on whether it failed or not. I do not know if such things are considered good practice or not, especially since if the constructor fails, the object will essentially become a zombie object - eg an object that should never be used.
I would think that exceptions are the only good way of handling this type of situation. You are not required to put try around a large block of code. It could be a single line if you will.

Also, if the object is never constructed, then the destructor will not be called since the object was never constructed in the first place.

Originally Posted by TriKri

Since an exception always breaks the scope, you cannot use an object if it's constructors throws exceptions.

Yes, and thus if it does not make sense for an object to be used since it cannot be sensibly constructed, you should throw an exception in the relevant constructor. An alternative is to construct the object anyway but in some kind of error state, then leave it up to the caller to check if there is an error (e.g., this is how the standard library I/O stream classes normally work). Yet another alternative is to use two stage construction, where you first create the object then initialise it by calling some function, thus the return value of the function can be an error code.

Originally Posted by TriKri

Consider the following scenario:

This declares a function that takes no arguments and returns a MyClass object:

Code:

MyClass MyObj();

Originally Posted by TriKri

Now, if the default constructor can throw an exception, you would have to wrap it in a try block:

The problem is with what you want to do: "A lot of code that may use MyObj, depending on the result of the constructor call". It does not make sense to use MyObj if the constructor fails. If it makes sense, then the constructor should not fail.

Originally Posted by TriKri

What happens here is that we will have to write the code two times. One time in the try block (since we want to use MyObj before it goes out of scope), and one time outside of the try block (since we still want to run the code if the constructor fails). The amount of code will almost double.

Yet, even if you want to do something as insensible as you currently want this duplication is not a must: the duplicated code can be moved to a function.

Originally Posted by TriKri

So my thought was that, if you for example want the thing that caused the exception to be acceptable (i.e. you want the program flow to continue in spite of it, and that not everything just bailes out), maybe you shouldn't use an exception. Maybe one should use some other method instead, like indicating in some way the result of the constructor call (typically a flag would be used), rather than having to leave the scope due to an exception.

Yes. However, note that your example supposes that you want to use MyObj even if its constructor fails. More likely, you want to recover from this failure, or at least log it, and the recovery will not involve MyObj, thus the code in the catch block will not be a duplicate of the rest of the code in the try block, and in fact could well be in some function that calls this one.

Originally Posted by TriKri

I also assume that if the constructor throws, the object will never have existed, hence the destructor won't be called.

Yes. I suggest that you read GotW #66: Constructor Failures.

Okay. I came to think about this since I'm defining a class and I was wondering if the constructors should be allowed to throw exceptions or not. But what seems to be the case, is that throwing exceptions in constructors is generally accepted, so I will allow the constructors to throw exceptions.

What I meant by "a lot of code that may use MyObj, depending on the result of the constructor call", is that it can use it if the constructor succeeds, but it shouldn't otherwise. The thing is that the code can be a mixture of code that don't use MyObj, and code that does (if the constructor succeeds), hence it could be inseparable, at least potentially. Maybe it never occurs, I was just thinking of what could potentially cause a problem. As you say, the code can probably be placed in another function too.

Alternatively, one can use a MyClass*, and create the object with new, and when the try block is left, the object isn't lost. But this feels like a workaround, especially since new could fail too.

Thanks for the replies!

Anything whose scope is inside the try block will disappear when it ends. But you are making workarounds.
In your try block, you should put code that depends on the code above to succeed in order to execute. In that case, the code will be skipped if one line of code fails.
If you think you can recover from something, then you should put a local try block around that which you can recover from. So even if you already have on instance of class X and you fail to create a new instance of class X, you can still set a pointer to the already existing instance of class X.
Of course, the pointer in question here must be outside the local try block.

The thing is that the code can be a mixture of code that don't use MyObj, and code that does (if the constructor succeeds), hence it could be inseparable, at least potentially.

That sounds extremely contrived. Do you have a concrete example of such code?
The only case I can think of is opening a log that simply shouldn't be written to if it can't be opened.

Originally Posted by CornedBee

That sounds extremely contrived. Do you have a concrete example of such code?

No, I haven't; I just thought that maybe, it can happen. That was why I went here to see what you thought about it; I mean, if there is any potential problems that can arise, someone here must know about them.

But thank you once again for your replies.

I cannot see that such a situation like yours can occur.
You would naturally separate code that relies on the object that you construct and that which does not. And you would also separate code that relies on the object being constructed and code that does not.
In all those cases, the duplicate code problem should never occur.