wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes adding exceptions in the interface provided by Sun Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "adding exceptions in the interface provided by Sun" Watch "adding exceptions in the interface provided by Sun" New topic
Author

adding exceptions in the interface provided by Sun

Alberto Ivo
Ranch Hand

Joined: Jul 06, 2007
Posts: 39
Hello guys..

I would like to know if we are allowed to add some excpetions to the interface provided by Sun in our assignment.

In my interface, I have only two exceptions: RecordNotFoundException and DuplicatedException.

I want to add IOException... Is it allowed? Or just make these two exceptions extends IOException...

What can I do?

Thanks in advance.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

if you extend RNFException from IOException, you say "a RNFException is an IOException" and that's not true at all. So extending the RNFException (or DuplicateKeyException) from IOException would result in loosing (a lot of) points.

You could create a RuntimeException like DataAccessException or something like that. Catch the IOException, wrap it in a DataAccessException and rethrow that one. Advantage will be: if the it-manager decides to use for example a Oracle-database instead of the flat file, you won't have IOExceptions but SQLExceptions. And those you can also wrap in the DataAccessException so you won't have to change anything to your interface, just the implementation class will be different

Kind regards,
Roel


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

Joined: Jul 06, 2007
Posts: 39
Thanks Roel.. Your reply helped a lot...

Let me try to explain what I want:

I have the interface provided by Sun (DBMain) and I'm trying to implement the RMI. so I made a remote interface like this:



This way, all methods in DBMain are in DataRemote, right? So, I implemented the remote class, like this:



So far, so good, the problem is: all methods in this class have to throw RemoteException, but as DBMain methods don't throw this exception, I can't throw it in DataRemoteImpl either...

So, what can I do now?

thanks a lot.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

Alberto,

I'm not at the RMI-part yet, so what i'm planning to do is to create a business interface with just 2 methods (the only ones your gui can call): book and find. instead of exposing the complete DBMain-interface.
And because this is a newly created interface you are completely free in which methods you add and which exceptions they can throw.

Good luck,
Roel
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Alberto,

Have you looked at the adapter pattern?

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Roel De Nijs wrote:... what i'm planning to do is to create a business interface with just 2 methods (the only ones your gui can call): book and find.

I know you can pass with this concept, but I personally believe it is wrong. For a detailed discussion of the pros and cons of thin versus thick clients, see "Should lock methods be callable by the client".

Regards, Andrew
Alberto Ivo
Ranch Hand

Joined: Jul 06, 2007
Posts: 39
Thanks a lot Andrew..

I'm reading your book.. fascinating!!!
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

Andrew Monkhouse wrote:For a detailed discussion of the pros and cons of thin versus thick clients, see "Should lock methods be callable by the client".

Regards, Andrew


I read the very, very long thread

My opinion is that 2-layer approach is just bad design. If you want to use the bookRoom-method from my business-interface from another application you can just call that method and it will work fine. In a 2 layer-approach you'll have all that code in your client-code and you'll have to duplicate that code in the other application. And duplication of code is never a good idea...
And if someone wants to use a thick client, he/she can just add the lock/unlock/... methods to the business-interface and implement them, and so those methods are also exposed to the client. but i choose the 3-layer approach because i feel that's a lot better than 2-layer approach and because you split the code (client, business, database) it will be a lot more clear and obvious for a junior programmer (what's also one of the requirements)

And another remark: in the thread you mentioned there is a whole lot going on about a few sentences and which words to emphasize in those sentences. That leads to some quotes like e.g. one of yours
I think you inadvertantly just provided me with more amunition

Not every one (including myself) is a native english speaker, so if it comes to that kind of detailed interpreting a sentence that could decide about passing or failing, i don't think that's fair to the not-native speakers
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Roel De Nijs wrote:My opinion is that 2-layer approach is just bad design.

Agreed. But the question was not about what was desirable, nor what was a good / better / best design - the question was what we thought the specification was asking for.

Roel De Nijs wrote:i choose the 3-layer approach because i feel that's a lot better than 2-layer approach and because you split the code (client, business, database) it will be a lot more clear and obvious for a junior programmer (what's also one of the requirements)

As was mentioned in that thread, you don't really have a 3 tier system - you have a 2 tier system where you have logically put the business logic in the same tier as the database. You may have separated the business logic into it's own packages (which would be a good thing), but that in itself doesn't make it a 3 tier system. You could similarly have the business logic in it's own package in a thick client system (which would allow for reuse).

Roel De Nijs wrote:And another remark: in the thread you mentioned there is a whole lot going on about a few sentences and which words to emphasize in those sentences. That leads to some quotes like e.g. one of yours
I think you inadvertantly just provided me with more amunition

Not every one (including myself) is a native english speaker, so if it comes to that kind of detailed interpreting a sentence that could decide about passing or failing, i don't think that's fair to the not-native speakers

Funnily enough, we had a good diversity in the people discussing the wording semantics. Jim was the only American. I am an Australian, and Tony is English. From memory Vlad and Ulrich are German. Phil was from Belgium. (Unrelated side note: some of the most correct English users I have come across were from when I worked in Holland - my Dutch and Belgian colleagues would frequently correct my English. )

More importantly though, I think one thing that many people missed in that discussion is that it is not a discussion about what could result in a pass or failure. It is a general discussion on what some of us believe the specification is asking for. Both Jim and I (the biggest proponents of exposing the interface's methods to the client) stated that we believe that users can pass with a thin client solution. I also made that clear in my response to where you stated that you were going to only expose business method, and I said that "I know you can pass with this concept..."

Regards, Andrew
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

Andrew Monkhouse wrote:
As was mentioned in that thread, you don't really have a 3 tier system - you have a 2 tier system where you have logically put the business logic in the same tier as the database. You may have separated the business logic into it's own packages (which would be a good thing), but that in itself doesn't make it a 3 tier system. You could similarly have the business logic in it's own package in a thick client system (which would allow for reuse).


You're right, it's not a real 3-tier system, but seperating the business-logic from the data-access or seperating the business logic from the gui code is a must for reusability and code readibility.

Andrew Monkhouse wrote:my Dutch and Belgian colleagues would frequently correct my English.


Yeah, dutch is only spoken by dutch and flemish (dutch-part of belgium, just like me) people, so we have to learn some other languages like english or french if we want to go international. But maybe i have to read the instructions a bit more careful because i pay attention to the "musts" but that's quite it. The sentence "Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. " is for me not more than "make sure your server can handle multiple incoming requests" but certainly not the whole 4-page-discussion

As a side note: i'm for a while wondering if it's allowed to add some methods to the given interface? or do you have to extend it? because it says "you must implement the interface", but if you add some methods and you implement the whole interface, you are fulfilling that "must" IMHO.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: adding exceptions in the interface provided by Sun
 
Similar Threads
NX:Am I allowed to modify the "DBMain" interface?
Propagating exceptions to client
Consuming IOExceptions in database layer
Doubt about Locking in URLyBird 1.1.2
RemoteException and DatabaseException