Java design question about constructors with exceptions
I don't like to have Constructors that can fail and throw a bunch of exceptions. Especially not exceptions that are reasonable to occur sometimes and that you expect to be possible to handle.
In this case, there is a hardware device that hopefully is connected to the computer.
However, if it isn't I will get an exception in the managing class (a singleton) in its java constructor.
I want to work away from that, but don't like the idea of having to call init on the singleton to get it working.
In this case, there is a hardware device that hopefully is connected to the computer.
However, if it isn't I will get an exception in the managing class (a singleton) in its java constructor.
I want to work away from that, but don't like the idea of having to call init on the singleton to get it working.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
but don't like the idea of having to call init on the singleton to get it working
Why?
You're right - ctors should neither catch, nor throw exceptions
I disagree.
A constructor can throw an exception if you have attempted to construct an object in an illegal state.
A constructor can throw an exception if you have attempted to construct an object in an illegal state.
I agree with gurpsbassi, if an object has requirements and those requirements fail then the object is not valid. Throwing an exception is appropriate.
Firstly, I will say that I DON'T agree that there is some blanket rule that constructors throwing exceptions are BAD.
Whether you do or not should simply be a matter of a design choice with your particular requirements in mind. Without knowing too much about YOUR particular requirements, it's hard to give and definite guidance but some things that I would consider are...
If it is likely that at some point later, the device DOES get connected to the computer and your code can proceed normally, then perhaps I would allow the object to be constructed and then provide a .connect() method, that the calling code can call regularly to attempt to talk to the device. This is even more true if there are other methods on the object that would be valid to call even when the device is not connected, eg. methods to get connection details maybe like a port or something or to get the status of the last connection attempt or other troubleshooting possibilities, etc. Yes, you can still just call the constructor repeatedly, and get the status of the attempt back in the exception message (if it fails) but you are limited in that is the ONLY way to get info back.
On the other hand, if it failed to connect, and if it was unlikely then that it ever would be able to connect during this execution of the code and/or there is nothing really useful that the object could do in this unconnected state, then yeah sure, have the constructor throw the exception and the calling code can deal with it appropriately.
Whether you do or not should simply be a matter of a design choice with your particular requirements in mind. Without knowing too much about YOUR particular requirements, it's hard to give and definite guidance but some things that I would consider are...
If it is likely that at some point later, the device DOES get connected to the computer and your code can proceed normally, then perhaps I would allow the object to be constructed and then provide a .connect() method, that the calling code can call regularly to attempt to talk to the device. This is even more true if there are other methods on the object that would be valid to call even when the device is not connected, eg. methods to get connection details maybe like a port or something or to get the status of the last connection attempt or other troubleshooting possibilities, etc. Yes, you can still just call the constructor repeatedly, and get the status of the attempt back in the exception message (if it fails) but you are limited in that is the ONLY way to get info back.
On the other hand, if it failed to connect, and if it was unlikely then that it ever would be able to connect during this execution of the code and/or there is nothing really useful that the object could do in this unconnected state, then yeah sure, have the constructor throw the exception and the calling code can deal with it appropriately.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial