Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2006

Tip: Looking for answers? Try searching our database.

Declaring and implementing exceptions inside interfaces?

Thread view: 
josh - 17 Dec 2006 20:17 GMT
Hello there,
I have question about application design (client side).
The problem is I have declared some basic interface for GUI form's
models, like this:

public interface BasicModel<K> {
  /*...other stuff...  */
  public void setEntityId(K id);
  public void edit();
  public void refresh();
  public void save();
  public void search();
}

But now I see this is not enough, because I would like my basic actions
throws some exceptions like: EntityNotFoundException or
EditNotAllowedException or something like this.

My question is: can I declare and implement that exceptions inside this
interface as public static classes? Yes, I know Java would not stop me,
this is legal to do so, but is that good solution? Look at this:

public interface BasicModel<K> {
  /*...other stuff... */
  public void setEntityId(K id)
    throws BasicModel.EntityNotFoundException;
  public void edit()
    throws BasicModel.SomeOtherException;
  public void refresh();
  public void save();
  public void search();

  public static class EntityNotFoundException extends Exception {
    /* some constructors or other methods */
  }
  /* other exceptions' classes */
}

My explanation for this is that these Exceptins are part of that
particular interface, so why not declaring them here? On the other hand
I have never seen such interfaces, so maybe this is stupid idea? What
you think? Should I declare them in separate classes? Why yes, why not?
John Ersatznom - 17 Dec 2006 20:44 GMT
> public interface BasicModel<K> {
>   /*...other stuff... */
[quoted text clipped - 11 lines]
>   /* other exceptions' classes */
> }

This is fine, if the exceptions are really local to the one interface
and don't occur more generally throughout the API of your package. If
they do, make them separate classes not nested anywhere.
Daniel Pitts - 18 Dec 2006 01:10 GMT
> Hello there,
> I have question about application design (client side).
[quoted text clipped - 38 lines]
> I have never seen such interfaces, so maybe this is stupid idea? What
> you think? Should I declare them in separate classes? Why yes, why not?

You could do this, however, those exceptions seem  like they are
actually rooted deeper in the object graph.  Especially
EntityNotFoundException seems like it should occure in your DAO layer.

I think that it would be best to create the exception classes in the
package where they are most likely to originate. It just seems cleaner
that way.
josh - 18 Dec 2006 01:34 GMT
Daniel Pitts napisał(a):

> You could do this, however, those exceptions seem  like they are
> actually rooted deeper in the object graph.  Especially
> EntityNotFoundException seems like it should occure in your DAO layer.

Hmm, maybe you are right, EntityNotFoundException could be generated by
session bean, when JPA fires its own exception for that.

I will follow yours and John's suggestions, thanks!
I should generally rethink my exceptions' strategy, but when I find that
interface good place, I think I would put there that declaration.
Daniel Pitts - 18 Dec 2006 02:26 GMT
> Daniel Pitts napisał(a):
> >
[quoted text clipped - 8 lines]
> I should generally rethink my exceptions' strategy, but when I find that
> interface good place, I think I would put there that declaration.
I have never seen someone use an inner-class as an Exception.  I would
advise against it.
Usually, inner classes are used only (or mostly) within the outer
class, or when directly communicating to the outer class.  I know there
are a couple of exceptions, but unless you have an overwhelming reason
to make it an inner class, make it a top level class.
josh - 19 Dec 2006 01:52 GMT
Daniel Pitts napisał(a):
>> Daniel Pitts napisał(a):
>>> You could do this, however, those exceptions seem  like they are
[quoted text clipped - 8 lines]
> I have never seen someone use an inner-class as an Exception.  I would
> advise against it.

Well, I have never seen that either, thats is why I am confused :)

> Usually, inner classes are used only (or mostly) within the outer
> class, or when directly communicating to the outer class.  

Do not forget I am talking about static inner classes, they are usable
without outer class.

I think the problem with Java is that you cannot expose only some
classes outside of your library which makes life hard when using
libraries (there are much to many public classes (there is nothing
between package scope and public scope). That is why I am trying to
avoid using top level classes whenever I can to make API more readable.
Declaring Exception for particular interface inside that interface was
what I though a good idea, but maybe I am wrong :/

> I know there
> are a couple of exceptions, but unless you have an overwhelming reason
> to make it an inner class, make it a top level class.

Yes, I do not have "overwhelming reason" :)

Thanks, bye!
Ed Kirwan - 19 Dec 2006 08:29 GMT
> I think the problem with Java is that you cannot expose only some
> classes outside of your library which makes life hard when using
[quoted text clipped - 3 lines]
> Declaring Exception for particular interface inside that interface was
> what I though a good idea, but maybe I am wrong :/

Kudos for the attempt. I'm in the school of
one-public-concrete-class-per-package myself. A die-hard Facader. Have
you checked the Sun-defined Java exceptions? If your hierarchy's not too
deep (or the distance your throwing your exception not that far) then a
Sun-defined exception may offer sufficient distinctiveness (as our Borg
friends might say).

You may, furthermore, find this of interest:
http://groups.google.se/group/comp.lang.java.programmer/browse_frm/thread/be00fa
992f76aa79/8e555b216fa7fc33?lnk=gst&q=gilad&rnum=1&hl=sv#8e555b216fa7fc33


.ed

Signature

www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.