This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Just wondering with the interface sun provides are the exceptions regarded as checked exceptions? Therefore other exceptions created say from the find method of the UrlyBird project, which has no exceptions declared in its interface, would have to unchecked exceptions,ie. RuntimeExceptions? Say, I discovered within the find method that one of my arguments in the array was larger than it was required to be and threw an IllegalArgumentException. Since no checked exceptions are detailed in the interface, would it be possible to wrap this error in a runtimeException and throw that? Can't think of any other ways of dealing with the exceptions that I have discovered in the find method, apart from doing this. Is this allowed by Sun, to throw as may RunTimeExceptions, as deemed necessary within methods but implement their checked exceptions? Sorry, if my understanding is wrong, new to project development.
My opinion is that you should eliminate any possible scenario that will cause your code to throw unchecked exceptions (IllegalArgumentException as you said). In my case it is assumed that all values passed to the Data.class are valid. To be more specific i'm filtering the values prior to updating, find, create etc.. and if there are invalid fields the user is notified, if the user agrees to continue like this the server has a mechanism to transform the invalid data to valid (Exceeding maximum width length, etc..) consequently eliminating the possibility of exceptions. After a synchronization method call the data refreshed with the actual data on the db file, as a result the user is aware if the update was successfull or not. In my Data.class the only exceptions (except the one from sun's interface) are IOException when flushing/reading the db file.
Nicolas Kal wrote:My opinion is that you should eliminate any possible scenario that will cause your code to throw unchecked exceptions (IllegalArgumentException as you said). In my case it is assumed that all values passed to the Data.class are valid.
Hum... I'm not sure if I agree with that. We have to develop our classes as flexible as possible. If an argument received does not fit your needs, then an IllegalArgumentException should be thrown. Not necessarily all arguments that are passed to your Data class will be valid. For instance, I guess you are filtering them in one layer above your persistence layer. What if someone wants to use your Data class out of the context of your application? So, in my opinion, we have to define our APIs (preferably via interfaces) without thinking who and where they will be used. This will promote reuse, flexibility and maintainability (which are certainly things that the assessors will pay attention when evaluating your application).
I completely agree with Roberto on this one. The Data class you are developing is some kind of API. And my javadoc of each method describe what is expected and when a RuntimeException, like IllegalArgument or IllegalState is thrown. For example if you make a call to the update method: data.update(1, null) you will get IllegalArgumentException, because my method expects a non-null array with the same length as the number of fields in the database schema. Otherwise the complexity of your code will increase, because you have to deal with a null-array, with an array of smaller/bigger length,... Throwing such RuntimeExceptions keeps your code simple and easy.
And of course in your BusinessService (or GUI) you are not catching such an IllegalArgumentException, because in your BusinessService (or GUI) you will guarantee correct data. These exceptions will only be thrown if the api (you designed) is not used correctly (according to the javadoc) by another programmer for example.
And of course in your BusinessService (or GUI) you are not catching such an IllegalArgumentException, because in your BusinessService (or GUI) you will guarantee correct data.
I agree with this, as far as I'm concerned it's whoever tests network and data layer together or its the gui layer that should catch these exceptions.
This is the approach I'm thinking of taking and have couple of questions.
(1) Is it ok for the constructor say, depending on design, to throw an IOException and to state this as a checked exception? Or this is not allowed and must catered for in the javadoc of the constructor? Basically need to know if the constructor in the Data class is allowed to throw whatever exceptions it needs and this is not seen as violating the interface.
(2) Is it ok from the functions provided by in the interface apart from the checked exceptions specified, to throw the rest of exceptions generated as runTimeExceptions, but specify in the javadoc which ones need to be passed on the gui user, for example, an IOException might be need to be passed to gui user if application failed to insert record correctly, while an IllegalArgumentsException would not crash the application from gui user point of view.
(1) your constructor is allowed to throw any exception (checked / runtime). certainly not violating the interface
(2) as long as you implement the interface (without changing it) and your code compiles, you are not violating anything. And if you implement a method that only throws RNFE, you can not throw another checked exception (will lead to compiler error). You can throw as many runtime exceptions as you want, without breaking the interface.
A remark about the IOException: is it a good idea to throw a IOException? Because that clearly indicates that your database is a file. What if the it manager decides to migrate to a RDBMS (like MySql)? Then you want throw IOExceptions but SQLExceptions for example, but your code expects IOException, so you have to wrap SQLException in IOException (or change your code). Not very extensible that approach.
So you are maybe better of using a (runtime or checked) DBException for example, which will be used to wrap the IOException (and when the RDBMS you just wrap the SQLException and you don't have to change any code).