• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

NX: Unspecified exceptions

 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all. I've been reading this board a lot while I begin to start work on this certification. If my following question has been asked then sorry for asking agin.
I am now working on the implementation of the DBMain interface. I'm presently working on the deleteRecord() method. It's signature is as follows:

My problem comes when I have call seek() and write() on my RandomAccessFile instance. Both of these methods throw an IOException but I'm not sure what to do with the exception. I'd like to throw some additional exception here (not a RuntimeException - that wouldn't seem right, I think). But, the assignment doesn't specify if I'm allowed to add an additional exception to the method signature or not (or does it and I'm missing something?).
So, I'm wondering if others have encounted this same situation and if they have any advice on what to do. Thanks!
Rich
 
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rich.
Nope, I wouldn't add a checked exception to this method signature if I were you, as modifying the provided interface might urn you a auto fail IMO.
What many people have done, including me, is to wrap the IOException in some runtime exception of your own, maybe something like RuntimeIOException, and then to catch that where you call this method from and unwrap it if you need to.
Helpful?
J
 
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Or is it ok to catch the IOException and wrap it in RecordNotFoundException? As to the end user, if an IO exception occurrs, he/she won't be able to see/work on the record anyway. The only thing is that this does not sound logical in terms of implementaton.
But could more be explained why wrap it in a RuntimeException is better than this?
Thanks
Bing
 
Jacques Bosch
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wrapping it in RecordNotFoundException is also an option, but the other way seems to feel more natural to me.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bing,
Think about when you could get an IOException and what you are going to do once you have got it.
I believe you should never receive an IOException unless something has gone wrong with the database itself (out of disk space / hard drive failure / other major problem).
Now if there is a major problem, you really want to have instant notification of that where possible. Sending a RecordNotFoundException will be giving the wrong information to the user (unless they check the cause of the exception - and there is no guarantee that anyone will check the cause (you might, but the next programmer may not)).
So it is possible that in sending the RecordNotFoundException, your users may not even realise that there is a problem, and may continue to book records in a potentially corrupt data file.
I think it is better to wrap it in an extended RuntimeException as that way you will get instantaneous notification that there is a major problem with your database. You can still catch this exception if you want to try and handle it / give the users a friendly "all your work is lost, have a nice day" type message.
Regards, Andrew
 
Ben Zung
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Andrew.
You reply had got me thinking for a while.
To catch and deal with an IOException is more of a design issue, rather about the probability of the occurrence. I'll certainly take your words for it.
Each RecordException thrown has a description message and in my design
right now, this exception will be thrown in following situation:
When the record is being locked by other thread: "Record is not available. Try later."
When the record is marked as deleted: "Record does not exist."
When the specified record number falls out of range(rarely but noted in choices.txt): "There is no such record"
When an IOException occurs: IOException is logged and its description is extracted and appened a message like this: "Can not obtain the record information. Fatal error: " + ioe.getMessage()
Guess I have to think through this again.
I did not adopt throwing an extended runtime exception was that I didn't recall I had ever seen any code piece do that or heard of it until ranchers mentioned it here. So I conclude Andrew's opinions that this is legitimately fine solution.
Thanks.
Bing
[ April 29, 2004: Message edited by: Bing Yuen ]
 
Richard Everhart
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for all the replies.
Creating a RuntimeException and throwing that sounds like the best idea. I'm already doing something similar by throwing my own extension of Exception in private and protected methods in my DBMain implementation. Now, to prevent too many exceptions from poping up, I'm considering turning that Exception into a RuntimeException and just using that. Thanks again!
Rich
 
Ben Zung
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And I just read from the API regarding RuntimeException:
A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.
Thank you Rich for raising this question at the first time. It cleared out
one design flaw of mine at the least.
And truely, even some people think that the scjd is not worth the time and money, the whole process is a great learning experence. Especially some
genius created this ranch and are maintainting it.

Bing
[ April 29, 2004: Message edited by: Bing Yuen ]
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rich,

I'm considering turning that Exception into a RuntimeException and just using that.


It certainly is tempting, however it makes it difficult to catch the exception later (assuming you really want to catch it).
Extending RuntimeException allows you to catch the specific exception that was thrown. Using RuntimeException itself means you would have to catch every possible RuntimeException (most of which should not be caught), and then deal with them appropriately.
Regards, Andrew
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bing Yuen:
Each RecordException thrown has a description message and in my design
right now, this exception will be thrown in following situation:
When the record is being locked by other thread: "Record is not available. Try later."


Bing :
Can you explain the above, I didn't quite catch this. My understanding of the assignment is that the current thread is supposed to wait forever (without wasting cpu cyles) for the record, if the record has been locked by another thread, until it is unlocked. What do you mean by "is being locked" ?
 
reply
    Bookmark Topic Watch Topic
  • New Topic