Declaring and implementing exceptions inside interfaces?

Discussion in 'Java' started by josh, Dec 17, 2006.

  1. josh

    josh Guest

    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?
    josh, Dec 17, 2006
    #1
    1. Advertising

  2. josh wrote:
    > 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 */
    > }


    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.
    John Ersatznom, Dec 17, 2006
    #2
    1. Advertising

  3. josh

    Daniel Pitts Guest

    josh wrote:
    > 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?


    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.
    Daniel Pitts, Dec 18, 2006
    #3
  4. josh

    josh Guest

    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.
    josh, Dec 18, 2006
    #4
  5. josh

    Daniel Pitts Guest

    josh wrote:
    > 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.

    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.
    Daniel Pitts, Dec 18, 2006
    #5
  6. josh

    josh Guest

    Daniel Pitts napisał(a):
    > josh wrote:
    >> 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.

    > 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!
    josh, Dec 19, 2006
    #6
  7. josh

    Ed Kirwan Guest

    josh wrote:

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


    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....lnk=gst&q=gilad&rnum=1&hl=sv#8e555b216fa7fc33

    ..ed

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

    Download Fractality, free Java code analyzer:
    www.EdmundKirwan.com/servlet/fractal/frac-page130.html
    Ed Kirwan, Dec 19, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. James D Carroll

    Implementing "package" interfaces

    James D Carroll, Jun 28, 2004, in forum: Java
    Replies:
    4
    Views:
    452
    Chris Smith
    Jun 28, 2004
  2. Chris
    Replies:
    6
    Views:
    494
    Chris Uppal
    Nov 7, 2004
  3. Replies:
    13
    Views:
    720
    Dave Rahardja
    Feb 2, 2007
  4. Replies:
    27
    Views:
    766
    Wojtek
    May 5, 2008
  5. Veli-Pekka Tätilä
    Replies:
    7
    Views:
    149
    Veli-Pekka Tätilä
    Aug 20, 2005
Loading...

Share This Page