• 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

Never throw exception that SUN declares

 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my DB interface, the unlock method also throw RecordNotFoundException. I think it's reasonable for the lock and some other methods to throw this exception, like read, update, delete, because it is reasonable to first verify the existence of the record, then lock it or do some modification on it. But why unlock method need to throw RecordNotFoundException? I put locked records in a hashmap, and if unlock(recNo, cookie) is called, I'll check if the recNo is in the hashmap, if not, it will simply return, otherwise, it will remove the recNo in hashmap and return. I just don't know why bother throwing this exception. trying to verify the existence of the record will possibly cause IOException and maybe lower the performance.

I want to ask can I never throw this exception in code, though it was declared by SUN?
 
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mingwei,

My spec for B&S states that you MUST implement the interface. Bearing that in mind I wouldn't want to omit the exception even if I could justify it in my design choices. The worst case scenario is that it could cost you 150 bucks (or whatever) to resubmit!

I think there's a good reason to have the exception anyway. If your app is trying to unlock a record that isn't locked then that's surely an error condition, though perhaps not a very serious one. If you don't find the recNo in the HashMap, just throw the exception. No big deal. Your calling code can then just catch it and quietly log it as a warning, if you choose.

How does that sound?

Jules
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mingwei Jiang:
In my DB interface, the unlock method also throw RecordNotFoundException. I think it's reasonable for the lock and some other methods to throw this exception, like read, update, delete, because it is reasonable to first verify the existence of the record, then lock it or do some modification on it. But why unlock method need to throw RecordNotFoundException? I put locked records in a hashmap, and if unlock(recNo, cookie) is called, I'll check if the recNo is in the hashmap, if not, it will simply return, otherwise, it will remove the recNo in hashmap and return. I just don't know why bother throwing this exception. trying to verify the existence of the record will possibly cause IOException and maybe lower the performance.

I want to ask can I never throw this exception in code, though it was declared by SUN?



My interface doesn't require that, but I suppose if you did
lock
delete
unlock
there is some justification when doing the unlock to throw a RecordNotFound, many real systems unlock records immediately on deletion, so no unlock call is needed. It really depends on whether you are dealing with locking of actual records or the locking of numeric resources. In my project the LockManager only locks numeric resources, the Data class checks for record existence on methods that require it.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Julian Kennedy:
Hi Mingwei,

My spec for B&S states that you MUST implement the interface. Bearing that in mind I wouldn't want to omit the exception even if I could justify it in my design choices. The worst case scenario is that it could cost you 150 bucks (or whatever) to resubmit!

I think there's a good reason to have the exception anyway. If your app is trying to unlock a record that isn't locked then that's surely an error condition, though perhaps not a very serious one. If you don't find the recNo in the HashMap, just throw the exception. No big deal. Your calling code can then just catch it and quietly log it as a warning, if you choose.

How does that sound?

Jules



RecordNotFound does not mean that the record wasn't in the Map, it means its either outside the file or has been deleted.

If its not locked anymore, my code would throw a SecurityException. Oddly the documentation for that exception is also suspect. For updateRecord it says "throws SecurityException if the record is locked with a cookie other than lockCookie" while for unlock it says "Cookie must be the cookie returned when the record was locked, otherwise throws SecurityException." The documentation for unlock is clear, but the documentaion for updateRecord doesn't specify what action to take if the record isn't locked at all.
 
JulianInactive KennedyInactive
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm, good point Peter! Good job you were paying attention.

Looking at my interface, the unlock() method does throw a RecordNotFound exception though it doesn't say under what circumstances it should be thrown (perhaps that's [incorrectly] assumed to be self-evident).

However, as you demonstrate with your "delete" example, it's clearly a nonsense. So, my intention is to implement the interface as it is and then simply document that RecordNotFound in never thrown by unlock(), stating the reason.

Now I come to think about it I think I've seen that conclusion on an earlier thread elsewhere on this forum. Wasn't up to that point at the time though.

Jules
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I find in my project I have to resort to exceptions where any error causes my program to not execute something very important. I have to do this since there is no other good way to make the error known to higher-level functionality. RecordNotFoundException fits into this scheme quite well.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Anton Golovin:
I find in my project I have to resort to exceptions where any error causes my program to not execute something very important. I have to do this since there is no other good way to make the error known to higher-level functionality. RecordNotFoundException fits into this scheme quite well.



I don't use RecordNotfound for things other than being unable to find a record. There are plenty of IOExceptions that need to be thrown, but can't because they are checked exceptions and are not declared. I also have exceptions such as FileFormatException that are checked exceptions.

What I've done with these, all of which are fatal to the server is to wrap them in a RuntimeException that I've called DataException. This takes an exception as an argument, allowing chaining. eg.


This can be caught at higher levels such as the network or business layers and the cause can be extracted and rethrown. In my case, I'll catch it and shut down the database, since these all indicate a corrupted file. Once the database shuts down the network will break all connections and the server operator will be prompted for a new database file.
 
JulianInactive KennedyInactive
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter's solution is an option that I have considered in my design (which I haven't implemented yet). Of course what we really want to do is to use checked exceptions. Clearly we can't change the DB interface, but can we use checked exceptions without changing it?

Is this code legal?

I only ask as I don't have access to a Java compiler here to check it out myself.

Jules
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Julian Kennedy:
Peter's solution is an option that I have considered in my design (which I haven't implemented yet). Of course what we really want to do is to use checked exceptions. Clearly we can't change the DB interface, but can we use checked exceptions without changing it?

Is this code legal?

I only ask as I don't have access to a Java compiler here to check it out myself.

Jules



no, that doesn't compile, you get overridden method does not throw java.io.IOException

The popular choice other than what I suggest is to extend the exceptions that the interface supports and use something like


then use that to wrap the IOException. This works everwhere except for the FindByCriteria which doesn't throw any exceptions.

There was very long thread last year discussing this, I'll see if I can find it. They suggested at least 6 solutions. I'm not certain my solution is safe, since it could crash an automated testing program, so I might adopt one of the others.

Is there anyone who has passed using runtime exceptions to wrap the IOExceptions?
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's that very long thread from last year.
 
Their achilles heel is the noogie! Give them noogies tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic