Java design question about constructors with exceptions

mdoland
mdoland used Ask the Experts™
on
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.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2016
Commented:
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
Top Expert 2015
Commented:
I disagree.
A constructor can throw an exception if you have attempted to construct an object in an illegal state.
Mark OlsenSr. Developer
Commented:
I agree with gurpsbassi, if an object has requirements and those requirements fail then the object is not valid. Throwing an exception is appropriate.
Top Expert 2016

Commented:
It's true there are times when you need to throw an exception, but if you can avoid it, you should
IT Business Systems Analyst / Software Developer
Top Expert 2015
Commented:
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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial