 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / June 2005How to handle exceptions in constructor?
Hello everyone, When exceptions occur in constructor so that the instance of the object can not be created, should we throw the exception to the invoker of the constructor or simply catch the exception (and not throw it again)? I think we should not catch the exception (and not throw it again), since in this approach, the invoker can not see whether the instance of the object has been created successfully. I think we should throw the exception to let the invoker know that the instance of the object has not been created successfully, so that the invoker can peform appropriate actions. But I am not quite sure whether I am correct since I have not seen any constructors which throw exceptions before. Could anyone help? Thanks in advance, George George via JavaKB.com wrote: > Hello everyone, > [quoted text clipped - 9 lines] > instance of the object has not been created successfully, so that the invoker > can peform appropriate actions. I think so, too. > ... But I am not quite sure whether I am correct > since I have not seen any constructors which throw exceptions before. There are many, for example the constructors of java.io.FileInputStream, java.net.URL or java.rmi.server.UnicastObject . > Could anyone help? >  Signature"Thomas:Fritsch$ops:de".replace(':','.').replace('$','@') Thanks Thomas, >George via JavaKB.com wrote: >> Hello everyone, [quoted text clipped - 9 lines] > >> Could anyone help? Your reply is very helpful. regards, George George George via JavaKB.com coughed up: > Hello everyone, > [quoted text clipped - 12 lines] > whether I am correct since I have not seen any constructors which > throw exceptions before. It is perfectly reasonable to have constructors allow embeded exceptions to trickle upwards. *However* : 1. In fairly odd cases you'll want to catch an exception that isn't already part of the java.lang.RunTimeException tree, and rethrow it as one of your own. This is because RunTimeException and subclasses do not require a throws clause in the function definition, and you may really desire that your function not require this. In general, I would suggest making at least /some/ of your exceptions extend RunTimeException as well. http://java.sun.com/j2se/1.5.0/docs/api/index.html 2. You may also wish (and this is common) to catch many exceptions, and then fold the various exceptions into your own exception. This can then be thrown from your constructor, and no one, not even a purist from comp.object, would ob/ject/. [author ducks] ...[rip]... SignatureDoesn't /anyone/ know where I can find a credit card company that emails me the minute something is charged to my account? Thomas G. Marshall coughed up: > George George via JavaKB.com coughed up: >> Hello everyone, [quoted text clipped - 22 lines] > already part of the java.lang.RunTimeException tree, and rethrow it > as one of your own. I am hysterically unclear here, sorry. What I mean to say is that there are odd cases where you may simply wish to roll your own exception for the /sole/ reason to make the callers /not/ have to use a try/catch. If this is the only reason you do it, then it is called *Bad Design*, but I've seen it before. I should have labeled this has #2, and listed the second item below as #1. This is a mess of a message, and I sincerely apologize. > This is because RunTimeException and subclasses > do not require a throws clause in the function definition, and you > may really desire that your function not require this. So that your users do not have to use try/catch. > In general, I > would suggest making at least /some/ of your exceptions extend [quoted text clipped - 7 lines] > > ...[rip]... SignatureDoesn't /anyone/ know where I can find a credit card company that emails me the minute something is charged to my account? Thanks Thomas, >Thomas G. Marshall coughed up: >> George George via JavaKB.com coughed up: [quoted text clipped - 27 lines] >> >> ...[rip]... Never mind. Your replies are very helpful and you are a warm-hearted expert. : -) regards, George > I think we should throw the exception to let the invoker know that the > instance of the object has not been created successfully, so that the invoker > can peform appropriate actions. But I am not quite sure whether I am correct > since I have not seen any constructors which throw exceptions before. > > Could anyone help? You absolutely should pass the exception through, or at least throw another, if your object could not be successfully constructed. A constructor can throw Exceptions just like any other method SignatureYou can't run away forever, But there's nothing wrong with getting a good head start. --- Jim Steinman, "Rock and Roll Dreams Come Through" Thanks Stefan, >> I think we should throw the exception to let the invoker know that the >> instance of the object has not been created successfully, so that the invoker [quoted text clipped - 6 lines] >another, if your object could not be successfully constructed. A >constructor can throw Exceptions just like any other method Your reply is very helpful. regards, George Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.