Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: exceptions in class constructors

 
Hugh Johns
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am in two minds as to whether or not constructors should throw exceptions.
Example, in my project I have a Data constructor (Data class implements DBAccess) , this calls the constructor for a second class DataSchema which reads and stores all the schema data from the db file.
The DataSchema constructor as it reads the db file can throw IO exceptions, these are passed up to the Data constructor. This looks messy to me, but I do not see a way around it if I want to set up the schema data when I build a Data instance.
Any ideas on this ???
Regards
Hugh
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Hugh,
Personally I don't see a problem with a constructor throwing an exception. To me that is correct - otherwise how do you know if your object was constructed correctly or not?
Why do you feel that they shouldn't?
Regards, Andrew
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Hugh,
Before I say anything, I have to say "join the club." Thus far, I have found exception handling to be the most elusive piece of this assignment, for that matter in my real-life experience as well. Even locking, a bit of a mind-bender as it was, seems to be more straight-forward than the exception handling. That is why, I am persuing it in baby-steps working with experts like Andrew and Max. Hopefully we will hear more from Max when we start to gather steam. Andrew is always there, patiently and gently guiding us.
I have more or less the same design that you have, i.e., a DataSchema class which is used to read the fixed or the header part of the data file, and a data class which is instantiated within a DataAdapter class (adapter, facade, or the mediator - more or less or the same to me. Seems like more a matter of semantics than anything else - but then I am not a design patterns hotshot anyway). DataSchema is a Singleton in my design, which means (you may already know this) that only one instance is created which is shared by all users/clients of this class. Moreover, in a Singleton, the constructor is declared private since we don't want uncontrolled creation of the Singleton's instances. The only instance is created using a lazy instantiation (just before it is needed the first time) strategy by calling a public static method "getInstance()" in my case. I read in a previous thread Andrew's response that he likes to create a long "try" block and follow that up with a series of "catch" blocks starting with catching more specific and then broader exceptions. This is consistent with what we learned in Kathy's text for SCJP Exam.
I first catch the "FileNotFoundException" and then catch the "IOException", at this point, I have pretty much avoided facing the issue head-on. All I have done is to log the message using the logger and print the stack-trace. I don't have to declare that this constructor throws any exception or for that matter the public static getInstance method as well. If you are following the thread started by Davidd Smith called "NX: About data consistent", I am persuing this topic with Max and Andrew.
They are advising me to create a user-defined exception by sub-classing RunTimeException class to be called "FatalSystemException" or something similar which is bubbled up the chain all the way up to the user GUI with a dooms-day message in a user-friendly format (a bit of a contradiction here isn't it?) and then stop the program. The particular exception is called InterruptedException, but serves as a contextual example.
Coming back to the DataSchema class, first, since we catch or handle the exceptions here in the private constructor, we don't have to declare it. I can clearly see at-least one case, i.e., Magic Cookie value, being wrong which qualifies for a such a FatalSystemException. My thinking at this point is that in the Data class which has a reference to DataSchema class, we should compare the Magic Cookie constant value read in the Singleton DataSchema instance and throw FatalSystemException. Since it is a sub-class of the RuntimeException class, it doesn't have to be declared.
Anyway, that is where I am. Like I said before, "Join the Club."
Regards.
Bharat
 
Hugh Johns
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew / Bharat
Thank you for your replies, I can see the options open for handling exceptions at various levels in the project modules.
What I am finding hard to pin down is when to handle an exception, or when to pass it up to the GUI.
In some Java texts I have read, it advises to pass the exceptions up to the GUI, where it can be handled in a more user friendly manner (error dialog box). Max does something similar in the DVD project in his book, in the GUI level logs the exception, then chains it into a custom GUIException, which is passed to a GUIException handler method to give the error dialog box.
This seems like a straight forward approach, I assume as long as you are passing up exception with good string descriptions of the cause, the user can get a description for the error box.
It would appear there are very few cases where you would handle an exception at a lower level i.e. data class, mainly because the user will be interacting with the GUI only, therefore all feedback/error should come back through the GUI. The only exception to this would be minor exceptions which will not effect the program if logged then swallowed.
Any advice on the above assumptions.
Reagrds
Hugh
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Hugh,
You wrote:

It would appear there are very few cases where you would handle an exception at a lower level i.e. data class, mainly because the user will be interacting with the GUI only, therefore all feedback/error should come back through the GUI. The only exception to this would be minor exceptions which will not effect the program if logged then swallowed

That, more or less, is the extent of my understanding too. Let us hope, Andrew and Max can help us to better define exception handling for the assignment.
Regards.
Bharat
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Hugh and Bharat,
This is still a little high level to try and pin down exactly what to do in case of exceptions.
There are some cases (e.g. cannot open the file) that you probably just want to display an error message to the client, and allow them to try and open a different file.
There are some cases (such as failure to write to an already opened file) that the user is unlikely to be able to fix, and there is not much that can be done, so it might as well be fatal. Give the user a warning message, and exit ("System crashing, all your hard work lost, have a nice day" )
And there are some cases that you might want to try to handle internally (such as communication error - you might want to try and reopen your communication channel a few times before seeking instruction from the user).
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic