B&S - Implication of SecurityException in DB interface methods
Alan Mac
Greenhorn
Posts: 9
posted 11 years ago
Hi all,
I have the Bodgitt & Scarper v2.1.1 assignment.
So far, I have written my app using a DBAdapter class to wrap the business logic (including the lock/unlock calls) before calling the underlying methods in the Data class. For example, a book(...) call from client goes to a book(...) method in DBAdapter which calls the lock/update/unlock methods in the underlying Data class.
However, I've come across a problem. In my DB interface, the update(...) and delete(...) methods are defined as throwing SecurityException. So my data access implementation class, Data, must implement these methods, each throwing a SecurityException if the record is locked with a cookie other than lockCookie. This implies that locking/unlocking should be carried out in the Data class, rather than abstracted out into a business layer?
Also, the fact that update/delete methods in Data take a lock cookie as a parameter suggest that locking/unlocking should be done in the Data class.
Am I missing something here...
Thanks
A.
[ August 19, 2005: Message edited by: Alan Mac ]
I have the Bodgitt & Scarper v2.1.1 assignment.
So far, I have written my app using a DBAdapter class to wrap the business logic (including the lock/unlock calls) before calling the underlying methods in the Data class. For example, a book(...) call from client goes to a book(...) method in DBAdapter which calls the lock/update/unlock methods in the underlying Data class.
However, I've come across a problem. In my DB interface, the update(...) and delete(...) methods are defined as throwing SecurityException. So my data access implementation class, Data, must implement these methods, each throwing a SecurityException if the record is locked with a cookie other than lockCookie. This implies that locking/unlocking should be carried out in the Data class, rather than abstracted out into a business layer?
Also, the fact that update/delete methods in Data take a lock cookie as a parameter suggest that locking/unlocking should be done in the Data class.
Am I missing something here...
Thanks
A.
[ August 19, 2005: Message edited by: Alan Mac ]
posted 11 years ago
Hi Alan,
The way I read the instructions, in particular the information provided with the interface, is that your Data class must be capable of standing alone and providing all the functionality specified in the interface.
That is: it should almost be possible for somebody to take a Data class written by somebody else and use it as a replacement in your solution. Or take your Data class and use it as the building block for some other application.
But if you delegate functionality to some other class(es) you will not be able to meet this requirement: another programmer will not be able to use your Data class unless they also use your 'x' class. In which case, why have the methods in the Data class?
Regards, Andrew
The way I read the instructions, in particular the information provided with the interface, is that your Data class must be capable of standing alone and providing all the functionality specified in the interface.
That is: it should almost be possible for somebody to take a Data class written by somebody else and use it as a replacement in your solution. Or take your Data class and use it as the building block for some other application.
But if you delegate functionality to some other class(es) you will not be able to meet this requirement: another programmer will not be able to use your Data class unless they also use your 'x' class. In which case, why have the methods in the Data class?
Regards, Andrew
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Alan Mac
Greenhorn
Posts: 9
posted 11 years ago
Hi Andrew,
Yes, that's pretty much how I saw it too. I assumed Sun set these specifications so that they could run a test harness against the Data class to verify that the methods worked correctly. However, I've seen a lot of posts where people talk about abstracting the business logic (and locking/unlocking) into a DBAdapter class where they wrap the lock/unlock calls before calling methods in the underlying Data class. I guess this is a good idea but not appropriate in my case!
Again, thanks for your opinion on this one Andrew.
A.
Yes, that's pretty much how I saw it too. I assumed Sun set these specifications so that they could run a test harness against the Data class to verify that the methods worked correctly. However, I've seen a lot of posts where people talk about abstracting the business logic (and locking/unlocking) into a DBAdapter class where they wrap the lock/unlock calls before calling methods in the underlying Data class. I guess this is a good idea but not appropriate in my case!
Again, thanks for your opinion on this one Andrew.
A.
Jesse Xie Y.S.
Greenhorn
Posts: 20
posted 11 years ago
I just thinking about the SecurityException again. In this forum, every body all thought that the securityException should be a checked exception. But I don't think so.
User the CSR's don't know there are some cookie exist in URLyBird program, maybe they know how to correct the FileNotFoundException and RecordNotFoundException, but they don't understand the cookie and don't know how to correct the SecurityException too.
So, I think that SecurityException is not a checked exception. It's a runtime exception. It's occured only by programer.
User the CSR's don't know there are some cookie exist in URLyBird program, maybe they know how to correct the FileNotFoundException and RecordNotFoundException, but they don't understand the cookie and don't know how to correct the SecurityException too.
So, I think that SecurityException is not a checked exception. It's a runtime exception. It's occured only by programer.
MOON -- SCJP1.2
