Win a copy of 97 Things Every Java Programmer Should Know this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

B&S Data exceptions

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a problem with methods from a Data class :
public String[] read(int recNo) throws RecordNotFoundException;

public void update(int recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;

public void delete(int recNo, long lockCookie)
throws RecordNotFoundException, SecurityException;

public int[] find(String[] criteria);

public int create(String[] data) throws DuplicateKeyException;

public long lock(int recNo) throws RecordNotFoundException;

public void unlock(int recNo, long cookie) throws RecordNotFoundException,
SecurityException;.

They can throw only specified exception. What should I do with caught exceptions inside this methods(which are in throws declaration)? For example create method can throw only DuplicateKeyException, but inside it can appear IOException. Throwing a DuplicateKeyException is ridiculous and I can�t do nothing (leave empty catch). Do you have any idea what to do? Please help me.
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hum... I did not run into these problems, since I open the .db file when the application starts and put all records in a HashMap, so when creating a record, there's no risk to run into an IOException. Yes, throwing a DuplicateKeyException in these cases would be wrong (or not that right), but in your case, what you can do is throw unchecked exceptions, like RuntimeException. In many cases, I throw IllegalArgumentExceptions or IllegalStateExceptions.
 
Jakub Drzazga
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I considered to use what is given by DB interface. So if inside the update, read, delete or lock method would be caught an IOException the method will throw RecordNotFoundException which is available. If IOException is caught in the find method empty int array is returned. If IOException is caught in the create method -1 value is returned.

Do you think is it a good solution? I have doubts especially about returning -1 value which can be considered as bad programming practice.

Please help me
 
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I implemented and what I think is the best to do in this situation - throw your own unchecked exceptions. They don't modify the DB interface, so it should be safe.

Edit:
Oh, and you should not throw RuntimeException directly, but use a subclass of it. For IOException, maybe IllegalStateException is also suitable, but not IllegalArgumentException. Or, even better I think, you should create your own unchecked exceptions.
[ December 17, 2008: Message edited by: Alecsandru Cocarla ]
 
Jakub Drzazga
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that RuntimeExceptions are very dangerous. User of Data class would not know that the exception must be catch (and probably exception would be uncatch). It is a great danger to use it.

An I right?
 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well if they are so dangerous, why do we have them?

You can document them in the DB's javadoc. The javadoc does not change an interface.

However, there are a lot of approaches to this.
For me, wrapping IOException in RecordNotFoundException is not "nice".
 
Jakub Drzazga
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I must admit that I have doubts. Both solutions have advantages and disadvantages. I have to think about it for a while.
 
Roberto Perillo
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

For me, wrapping IOException in RecordNotFoundException is not "nice".



Agreed. An IOException is not a RecordNotFoundException. In your case, I really think the best option is to throw a RuntimeException, or a subclass of it. For instance, in my create method, if I don't get a String array of 7 positions properly filled (I only allowed the custumer ID to be null), I throw an IllegalArgumentException. They exist, let's use them!
 
Jakub Drzazga
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alecsandru Cocarla have already passed SCJD? If yes, what do they said about runtime exceptions?

If somebody else knows what examinators think about runtime exceptions please write.
 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, I did not pass the exam yet. I'll have the exam next week.

But I think you could do a search about these exceptions. I'm sure the issue has been discussed quite a lot on this forum.
 
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jakub Drzazga:
Alecsandru Cocarla have already passed SCJD? If yes, what do they said about runtime exceptions?

If somebody else knows what examinators think about runtime exceptions please write.



I have passed last year using the runtime exception approach.

The examiners will not be too concerned about which strategy you use, as there is no 'right' answer, many people have passed using all sorts of different approaches.

The poor specifications are a test of your ability to weigh up the pros and cons of a design choice and to then be able justify your choice.

Once your logic for selecting one particular strategy over the other is consistent and sound, then you will be fine.
 
They weren't very bright, but they were very, very big. Ad contrast:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic