aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Handling of RecordNotFoundException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Handling of RecordNotFoundException" Watch "Handling of RecordNotFoundException" New topic
Author

Handling of RecordNotFoundException

Liviu Carausu
Ranch Hand

Joined: Oct 07, 2004
Posts: 158
Hi all,
I wondered how are you handling RecordNotFoundException ? I decided to make it a checked exception.
Normally, if the DB implementation is correctly used, by reading only the records returned by the find()
method, the RecordNotFoundException should never occur, therefore it should be designed as a not checked exception.
But, because I choose not to lock the complete database when searching for records, it is possible that
some other users can delete records in between, and RecordNotFoundException to be thrown.
Here are in my opinion two ways to handle the RecordNotFoundException :
1) ignore it (and document it)
2) retry the search. (until no RecordNotFoundException occurs)
Any help ?
Thanks,
Liviu


Oracle Certified Master Java SE6 Developer(SCJD),
OCE JEE 6 JSP and Servlets Developer.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Liviu Carausu wrote:
1) ignore it (and document it)
2) retry the search. (until no RecordNotFoundException occurs)

No, don't ignore exception, at least display error message to inform user what happened.
RecordNotFoundException can be RuntimeException, you can register a global exception handler which just display message of uncaught exceptions.

Don't retry to search until RecordNotFoundException occurs, I don't know why you think to do that, your application will be frozen, because it will be stuck in infinite loop to try to find a not exist record.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5545
    
  13

Hi Liviu,

I don't completely agree with Kengkaj. For your problem some different solutions exist. Take a look at following similar threads, i think they will help you a lot:
- Thread A
- Thread B
- Thread C

If you still have questions after going to these threads, just ask


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Hi Roel, if you disgree, could you please to let me know what you disagree and why?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5545
    
  13

Hi Kengkaj

I disagree about your quote:

No, don't ignore exception, at least display error message to inform user what happened.
RecordNotFoundException can be RuntimeException, you can register a global exception handler which just display message of uncaught exceptions.


First of all because RNFE is mentioned in the throws-clause of your method signature, it should be a checked exception in my opinion. Normally you wouldn't put runtime exceptions in the method signature. I've never seen a method in an interface like "void doIt() throws NullPointerException, ArrayIndexOutOfBoundsException;". I consider it as bad programming. Runtime exceptions are usually caused by data errors, like arithmetic overflow, divide by zero, ... . Runtime exceptions are not business related exceptions. In a well debugged code, runtime exceptions should not occur.

Secondly i would just ignore the exception as it's expected to happen with the approach Liviu choose to follow. Because you have a find-method which returns more record numbers than you will need: your find will return startsWith-matches and your gui should show only "exact matches", so you need to filter the records again in your gui. so because he wants not to lock complete db when executing search it could happen that a record is deleted between find and the read (to test "exact match"), so i would not inform user of a possible RNFE.

I agree with you about the retry of the search, that's not a good idea. there are other solutions to solve this issue (described in the threads i mentioned), but if he definitely won't "lock" the server, then the possiblity of getting a RNFE when reading the records is inherent to the approach taken and you catch it, and maybe log it, but you don't have to inform the user

But that's my opinion of course and you don't have to agree with me

Kind regards,
Roel

[edit]Placed your quote in a code-block instead of quote-block[/edit]
Liviu Carausu
Ranch Hand

Joined: Oct 07, 2004
Posts: 158
Kengkaj Sathianpantarit wrote:
No, don't ignore exception, at least display error message to inform user what happened.
RecordNotFoundException can be RuntimeException, you can register a global exception handler which just display message of uncaught exceptions.

Don't retry to search until RecordNotFoundException occurs, I don't know why you think to do that, your application will be frozen, because it will be stuck in infinite loop to try to find a not exist record.


Hi Kengkaj,
Thanks for your answer.
If you read again, you will see that I ment
Liviu Carausu wrote:
1) ignore it (and document it)
2) retry the search. (until NO RecordNotFoundException occurs)

The problem is that even if you have a thin client, when you want to present the search results to the users you have an operation
in two steps :
1) call find method()
2) read the records using the int[] returned by the find() method.
At step 2, when you loop through the records reading them, it is possible that a delete operation from
another user comes in between and causes a RecordNotFoundException to happen. It even could be possible that
somebody modifies the element in between and some wrong results are displayed to the user.
Completely clean will be to obtain a database lock and to make this two operations atomic but this will have as result making the
concurrent operations slower (any write operation must wait for the search operation to finish...). Somehow I do not like this ideea.
It must be a standard way to do such basic things, in any database this should be a standard operation.
How have you guys implemented ? Can somebody hint to a good design principle in this case ?

Thanks,
Liviu

Liviu Carausu
Ranch Hand

Joined: Oct 07, 2004
Posts: 158
Roel De Nijs wrote:Hi Liviu,

I don't completely agree with Kengkaj. For your problem some different solutions exist. Take a look at following similar threads, i think they will help you a lot:
- Thread A
- Thread B
- Thread C

If you still have questions after going to these threads, just ask


Hi Roel,
Thank you very much for your answer and for the links, they are really helpful for me. Reading the threads
I have realized that a "OR" search must not be necessary implemented, which will make my search algorithm
much more simpler ...
Would you really lock the database when making a search ?
Greetings,
Liviu
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5545
    
  13

Hi Liviu,

I implemented an extra find-method returning recNos + records. And my find-methods are OR-ing the different criteria because i think that's how it should be done, also taking possible future enhancements into account. If in future user want to search for hotel name or city, you have to change your find implementation or call 2 times find and then union both result sets. And in RDBMS doing a search with or-ing criteria is very common.
But it's just about interpretation, and i will use this explanation to argument my decision to use or in the find-methods.

And i'm locking my database when making a search, because i took the easiest approach for making my db thread-safe: singleton data-class with every method synchronized. performance is not a main requirement, but code simplicity is

Kind regards,
Roel
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Hi Roel, Thanks for your explanation.
Roel De Nijs wrote:Hi Kengkaj
First of all because RNFE is mentioned in the throws-clause of your method signature, it should be a checked exception in my opinion. Normally you wouldn't put runtime exceptions in the method signature. I've never seen a method in an interface like "void doIt() throws NullPointerException, ArrayIndexOutOfBoundsException;". I consider it as bad programming. Runtime exceptions are usually caused by data errors, like arithmetic overflow, divide by zero, ... . Runtime exceptions are not business related exceptions. In a well debugged code, runtime exceptions should not occur.

Well, the thing that you have never seen doesn't mean that it's not exist or it will be always bad, I think it's not a right attitude to think like that .

If you've never seen it I'll show you with very famous framework - Spring Framework.
http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/orm/hibernate3/HibernateTemplate.html
DataAccessException is RuntimeException.

Do you know Hibernate? Now, HibernateException is RuntimeException.
And do you know Java Persistence API (JPA)? IIRC, all JPA exceptions are RuntimeException, the following is an example:
EntityNotFoundException

And do you know that Java is only a mainstream programming language that uses checked exception? (I guess maybe all programming languages in this world except Java are bad )

But enough about it, I will not debate about checked exception and will not discuss about it more.

You have right to think checked exceptions are good, but others also have right to think another way .

PS. Projects that I developed of late use almost only RuntimeException.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5545
    
  13


And do you know that Java is only a mainstream programming language that uses checked exception? (I guess maybe all programming languages in this world except Java are bad )

That's true, Java is the best

And i do know Spring and Hibernate.JPA, using them on a project right now. Got a whole lot of these runtimes thrown in my face because e.g. my applicationContext.xml wasn't correct

the disagreement about a checked or a runtime exception is a minor issue (but i forgot to mention that). My biggest disagreement was my second point i made.

Kind regards,
Roel
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Roel De Nijs wrote:
Secondly i would just ignore the exception as it's expected to happen with the approach Liviu choose to follow. Because you have a find-method which returns more record numbers than you will need: your find will return startsWith-matches and your gui should show only "exact matches", so you need to filter the records again in your gui. so because he wants not to lock complete db when executing search it could happen that a record is deleted between find and the read (to test "exact match"), so i would not inform user of a possible RNFE.

I didn't know details like that. Are most people in this forum supposed to know all these details? Just curious.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5545
    
  13

Most of the people answering questions in the certification forums have done or are preparing to, so they know the details. That's my experience, but of course you are more than welcome here to give your thoughts about the stuff that's going on here
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11509
    
  95

Roel De Nijs wrote:

And do you know that Java is only a mainstream programming language that uses checked exception? (I guess maybe all programming languages in this world except Java are bad )

That's true, Java is the best

Note that there are strong reasons for not having checked exceptions. See this discussion for a view of why checked exceptions can be considered bad.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Handling of RecordNotFoundException