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

  2. 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
    1. Advertisements

  3. josh

    Daniel Pitts Guest

    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
  4. josh

    josh Guest

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

    Daniel Pitts Guest

    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
  6. josh

    josh Guest

    Daniel Pitts napisał(a):
    Well, I have never seen that either, thats is why I am confused :)
    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 :/
    Yes, I do not have "overwhelming reason" :)

    Thanks, bye!
    josh, Dec 19, 2006
  7. josh

    Ed Kirwan Guest

    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:

    Ed Kirwan, Dec 19, 2006
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.