Can I use throws in constructor?

问题:

I have to initialize file objects inside the constructor and for handling the exception, is it efficient using throws or should I go for try/catch?

回答1:

It's okay to throw an exception in the constructor. I know some of the Java library classes do so (URI for just one example). I think it's better to throw an exception than to return an object in an unknown or invalid state.

回答2:

Of course you can and throwing an exception is actually what I would do (instead of swallowing it in the constructor). You want to let the caller know that something unexpected happened, you don't want to return a non properly initialized instance. That said, it may be a sign that you are doing too much things in the constructor.

回答3:

Consider a constructor, or for that matter any method, to have a contract. The contract for a constructor is very simple - you give me (zero, one or more) parameters and I'll give you back a constructed object. Good practice would suggest that this object should have its internal data structures properly initialised and invariants intact, although there's nothing in the language to enforce this per se.

If, for some reason the constructor cannot hold to this contract, then it should throw an exception. That might be because the parameters passed (if any) were not acceptable (pre-condition failure) or some external problems (file-system full, heap exhaustion, network outage etc.) prevented it.

回答4:

You sure can (for example, FileOutputStream does).

Throwing an exception from the constructor should be done wisely - make sure you clean up after yourself cleanly. Throwing exceptions in a constructor is sometimes done in order to make sure RAII is held.

回答5:

To me, that's not a question of efficiency.

If you can react on the exceptional state and still create a valid or at least useable object, then handle it within the constructor.

Otherwise - in case the object is not usable - throw the exception back at the caller. In that case, he won't get an object and can't continue with an unusable/inconsistant instance which might produce errors in some other corners of the application.

回答6:

You are supposed to take the object to a safe state in the constructor, but let's imagine you want to open a file(for reading) that doesn't exists, throwing the exception is the only way. So it depends on the logic you implement

回答7:

I suggest try/catch, and throw usefull errors from your catches. This will give users a better sense of what is going wrong with your application. For example you should check for file existence, and properly formated conditions.

回答8:

Generally it is a bad idea to do heavy lifting in constructors: in many languages, you'll be restricted anyhow in what can be done about exceptions during construction.

回答9:

In general it is a good idea to have only simple logic in your constructor (for example setting private fields with arguments values). And set up your objects with other special "assemblers", "preparers" or "factories". The same is about get/set methods- they should be as simple as possible.

Sure it is possible to throw an exception from constuctor. But this is not a good practice.

回答10:

I think throwing exception in a constructor is an elegant way to indicate an error condition inside the constructor. Otherwise, you would have to create another function which initializes the resources, and call that function after the object is constructed.

回答11:

I'd go with 'throws' if you care about what is initialized in the constructor, which I guess you do.

If you hide the exceptions, then that will probably cause problems later on.

回答12:

Of course, it's actually used a lot in Java. For example,

public FileInputStream(String name)
                throws FileNotFoundException