Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Declaring and implementing exceptions inside interfaces?

Reply
Thread Tools

Declaring and implementing exceptions inside interfaces?

 
 
josh
Guest
Posts: n/a
 
      12-17-2006
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?
 
Reply With Quote
 
 
 
 
John Ersatznom
Guest
Posts: n/a
 
      12-17-2006
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.
 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      12-18-2006

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.

 
Reply With Quote
 
josh
Guest
Posts: n/a
 
      12-18-2006
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.
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      12-18-2006

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.

 
Reply With Quote
 
josh
Guest
Posts: n/a
 
      12-19-2006
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!

 
Reply With Quote
 
Ed Kirwan
Guest
Posts: n/a
 
      12-19-2006
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.l...555b216fa7fc33

..ed

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

Download Fractality, free Java code analyzer:
http://www.EdmundKirwan.com/servlet/...c-page130.html
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Declaring local variables inside loop Hendrik Maryns Java 37 02-25-2006 09:48 PM
declaring strings inside vs. outside of functions darrel ASP .Net 3 08-13-2004 03:57 PM
declaring variables inside for loops Grey Plastic C++ 3 08-10-2004 10:40 AM
Implementing exceptions of C++ in C Bernard C Programming 15 05-18-2004 02:22 PM
Implementing exceptions of C++ in C Bernard C++ 9 04-18-2004 10:51 AM



Advertisments