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