Can we put exception handling inside the constuctor

Question

3.50/5 (2 votes)

See more:

I got this question in an interview.The question is, can we have exception handling in the constructor and is it safe to throw an exception from the constructor.

I tried a sample code by putting a try catch block in the constructor but I didnt get any error.Can any one please explain about this

Posted 26-Jul-15 1:40am

krish0969

Add a Solution

Comments

Afzaal Ahmad Zeeshan 26-Jul-15 7:56am

If, your constructor is based on another constructor, such as initializers for other base objects. Then, you can check whether the types were initialzed correctly.

Remember, constructors are also functions.

Sergey Alexandrovich Kryukov 26-Jul-15 11:39am

There are two very different things: handle exceptions in a constructor or throw an exception?
—SA

3 solutions

Solution 2

Have a look at this page: "Exceptions and Error Handling"[^].

Posted 26-Jul-15 4:29am

CPallini

Comments

Sergey Alexandrovich Kryukov 26-Jul-15 11:57am

There are some good points in that article and some are probably missing (5ed), but — please see my comment to Solution 1 (about the value of an advice) and my Solution 3.
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Afzaal Ahmad Zeeshan · Accepted Answer · 2015-07-26T02:03:00

Read my comment to the question, continuing from there. Remember, constructors are also functions. So, when you create a custom constructor logic you are basically trying to set up the underlying objects. If they are exposed to some errors and would work in a condition only, then yes. You need to handle the exceptions in the constructor context also.

But (IMO) it would be of no good. Suppose you are writing a constructor for an object that acts as the controller for your hardware; flash drive reader for instance. The constructor has to load the other base objects, such as connection over the ports.

C++

public:
  FlashReader() {
    // Construct the stream reader for the port
    _streamReader = streamreader::Reader(); // <-- Here
  }

Suppose, reader doesn't work, no matter of what problem. Adding a try catch block won't help you. It would be just as to prevent the application from breaking, only. Otherwise, adding a try catch block won't help you out in any way.

C++

public:
  FlashReader() {
    // Construct the stream reader for the port
    try {
       _streamReader = streamreader::Reader(); // <-- Here
    } catch (std::exception e) {
       // No difference made. 
    }
  }

That is why, although it is legal in C++ to write the try catch block. But, for what? That is the question you need to answer. Does it really matter, or is it worthy to add a try catch block, or is it just another fancy thing to maintain a dead program in the memory. :-)

For a more clearer image of the problem that might be caused with this kind of behavior, read Solution 3 by Sergey. It shows you the image, and what are the possible candidates that might be expected with this pattern.

Also, what did your term safe means? Thread-safe or what? Safety of data is a concept about instance members. If a constructor throws an exception that means no instance was created, thus no discussion to take place about safety. Throwing exception from a constructor would be a good one, I'd say. Because, it would notify the user and break the program, instead of keeping it there in the memory to create a new stack for the custom error message.

Sergey Alexandrovich Kryukov · Accepted Answer · 2015-07-26T05:53:00

In addition to Solution 1: The answer could be more certain: yes and no. :-)

First of all, from your question, it is not clear what you are talking about. You are talking about handling exceptions, and in other place you are talking about throwing. Let's discuss throwing first.

Of course, it is possible to throw an exception from a constructor and then continue execution of the program in a safe way. But is it a good programming practice? Yes and no; without deep understanding of one's own design and consequences, it will likely be very bad, but it can be not bad for something well planned and designed. So, the technique should first become an object of a doubt.

The fundamental controversy is this: structured exception handling mechanism is the time machine which reverts everything to the first point of try up the stack. But what is reverted? Only the stack and the stack object, and, of course, not the side effects. The heap and the objects allocating heap and constructed is just one of such site effects, but it can be anything else.

For example, let's say, you have a constructor which creates some other objects on heap, and each of those objects also creates some other objects on heap. And, more importantly, your class is also a part of this chain, is used by some other class, and your object can also be created on heap. This is a very typical picture. Normally, you can handle an exception anywhere up the stack and have a freedom of abstracting out the exception (its location, some detail, and so on). With heap, you make your code depending on how and where the exception is thrown. The real problem is with our hypothetical "parent object" (when you develop some class for external, its use should be considered hypothetical): you can end up with half-constructed set of objects, with no way to find ends to revert the heap (that is, memory leak at best). I repeat: heap is just the most typical example of the problem.

But of course, without the side effects you can be fine. Even with the heap, if you fully control the situation in both cases, with the exception and without it. Which leads us to the problems of full exception handling inside a constructor.

What if you throw some exception is some constructor and catch it in the same constructor? (I repeat: it's not clear from your question if you meant that or not)? You will have all the same problems discussed above, only you have more control and can practically resolve the problem of correct construction in both situations (exception handled and not). But such goal would look weird. In case of handling exceptions outside of the constructor execution, you want to come to the situation where you have the object not created, and your execution context in the position as if you never tried. With handling inside a constructor, you can have it all handled, and actually created an object after an exception deeper in a constructor was thrown. I doubt the possible rationale of this design. But generally, handling exceptions too locally is a pretty bad idea. Exceptions are designed to isolate "regular" execution from exceptional. Therefore, it gives you the benefit of having very few points where you accumulate many possible exceptions on every stack, and handle the altogether. You have to strategically chose those points, and, of course, they are not in each function throwing exception.

See also my past answers:
Does Exception in C# Constructor Cause Caller Assignment to Fail?[^],
where was stored .net exceptions in operating system[^],
Unhandled Exception : Access Violation[^].

—SA