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
?
相关问题
- Delete Messages from a Topic in Apache Kafka
- Jackson Deserialization not calling deserialize on
- How to maintain order of key-value in DataFrame sa
- StackExchange API - Deserialize Date in JSON Respo
- Difference between Types.INTEGER and Types.NULL in
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.
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.
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.
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.
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.
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.