• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Handling IOException in Data Accessing

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all, would like to seek some advice in handling IOExceptions in the data access class.

Take for example the following method:


During the process of creating (writing into the database file), IOExceptions can occur. I had thought of 2 solutions:

1) Wrap the IOException in a custom exception (for example, CreationFailedException). However, am I allowed to introduce additional exceptions to be thrown?

2) Return -1 whenever creation fails.

Which one do you guys think is better or feasible?

Thanks in advance.

Zengwei
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Runtime exception.

I use a facade for my Data class, and switch the runtime exceptions back to checked exceptions. I do this to make the code more clear throughout the rest of the application.
 
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
same, Runtime...
 
Zeng Wei Chu
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi William, by switching runtime exceptions back to checked exceptions, do you mean using DuplicateKeyException to wrap IOException in my example? By the way, IOException is not a subclass of Runtime exception.

Sorry if i did not get your meaning.

Regards,
Zengwei
[ December 05, 2007: Message edited by: Zeng Wei Chu ]
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

"RuntimeException" don't have to be declare.Meaning, the interface provided by SUN forces you to declare/throw the "Checked" exception. Because of that Interface, you cannot throw any check exception other than what your Interface specifies.

However, RuntimeException (IllegalArgumentException, NullPointerException...Classes inheriting "RuntimeException") don't have to be declare and don't go against your contract.. Without being defined in your contract, you can throw them..

Having that said, it is good practice to define them in your implementation class (and since you are not allowed to modify your interface, you don't put it there..)
Try it, create a method, don't declare any "throws". You'll still be able to throw "IllegalArgumentException" because it is a "RuntimeException".

Regards,
Alex
[ December 05, 2007: Message edited by: Alex Belisle Turcot ]
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And I guess what William meant is: after catching the runtime exception (from the Object using his Data class), he creates a "normal" Exception (checked.. lets say Implementing "Exception").
Then, he throws this "checked" exception instead of throwing the runtimeException, which would be a little dirty!

Regards,
Alex
 
Zeng Wei Chu
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Alex, many thanks for the clear explanation. How about RandomAccessFile operations which can possibly throw IOExceptions within the methods during creation, updating and deleting of records? There are a few possible solutions which I have thought of:

1) Use the declared checked exceptions to wrap it. For example, using the DuplicateKeyException to wrap IOExceptions during record creation process. However doing so does not quite justify the name of the DuplicateKeyException.

2) Declare a class which extends the RuntimeException. For example, using of CreationFailedException (a RuntimeException) to wrap the IOException. But is it correct to do it this way?

3) Catch the IOException in the create( ) method and log it. But the client will have no means of knowing that creation actually fails.

4) return -1 when IOException occurs. But the disadvantage would be coding will not be that readable.

Had been pondering over this IOException haha...headache. Are there any other ways to handle IOExceptions?

Regards,
Zengwei
[ December 05, 2007: Message edited by: Zeng Wei Chu ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic