Declaring and implementing exceptions inside interfaces?

[josh]

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]

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.

 

[Daniel Pitts]

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.

 

[josh]

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]

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.

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]

Daniel Pitts napisał(a):

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]

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