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.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

but don't like the idea of having to call init on the singleton to get it working


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.
Mark OlsenSr. DeveloperCommented:
I agree with gurpsbassi, if an object has requirements and those requirements fail then the object is not valid. Throwing an exception is appropriate.
It's true there are times when you need to throw an exception, but if you can avoid it, you should
mccarlIT Business Systems Analyst / Software DeveloperCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.