• 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

adding exceptions in the interface provided by Sun

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Alberto Ivo
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
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 Alberto,

Have you looked at the adapter pattern?

Regards, Andrew
 
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

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
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot Andrew..

I'm reading your book.. fascinating!!!
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
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

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
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic