This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes exceptions in own package Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "exceptions in own package" Watch "exceptions in own package" New topic
Author

exceptions in own package

manuel aldana
Ranch Hand

Joined: Dec 29, 2005
Posts: 308
i am a bit unsure whether to put exception classes in a own child. the parent package should be the package which relates directly to theses exceptions.

for instance:
package.doSomething
package.doSomething.exceptions

if i see other apis (like j2se) this is not done often. but in my view when having exceptions-packages, you see more quickly what "basic" package classes exist and don't get distracted by exception artifacts.
on the other hand the number of packages increases.
what do you think? keep exceptions classes in one package with other classes or take the move?

thanks.


aldana software engineering blog & .more
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by manuel aldana:
...
package.doSomething
package.doSomething.exceptions
...
what do you think? keep exceptions classes in one package with other classes or take the move?


I personally don't like the extra package and leave the exception in the same package where it starts to be thrown. With this approach I have much less packages. It also helps to think of components and subsystems other than to think of client, server, exception, etc. package splitting.


SCJP, SCJD, SCWCD, SCBCD
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
You can manage dependencies between packages in different ways for different goals.

If I make a package of cool utilities that I'd like to shrink wrap and sell (ok, nobody does that in Java) or share with friends, I'd probably put any custom exceptions right in the package. That way you could add the one package to your project and use my utilities. I think of that as goal == reuse.

But look how Sun made JDBC. They defined all the exceptions in packages long with a lot of interfaces and abstractions. Database vendors like MySQL or Oracle or IBM have to import those exceptions and use them in their drivers and database code. So when you use IBM drivers you import JDBC and IBM packages. This is more like goal == plugins. We can plug in Oracle or UDB.

This topic gets pretty interesting. This Paper by Robert Martin gets into package architecture principles. He doesn't necessarily mean Java package, but a unit of construction and deployment, but the ideas are all applicable. See if that makes sense to you.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I dont see a problem with that. But if you are able to create this level of exception seperation then it probably does not matter because likely this is all that is in your library anyway. If your library is bigger than this one package, then its typically difficult to use a set of exceptions in just one package. Plus perhaps even there is a heiracy of exceptions for everything in the library.

So I don't see a problem. Keep the exceptions in the library that declares the interfaces that throw the exceptions. package seperation is really whatever makes your job easier and more logical.
manuel aldana
Ranch Hand

Joined: Dec 29, 2005
Posts: 308
thanks for your thoughts.

i think i will stick with the package seperation, i.e. to put exceptions in an own package. this way users don't get distracted by exceptions classes.
formerly i had the same opinio that exception should reside in the same package as the classes which are primarily throwing them. but i got to the point where overview is more important than numbers of packages.

my main motive force for package reordering was, that some team members were telling me that when exploring the code they were primarily interested in "working" classes and got somehow distracted with exceptions artificats.
further more by creating an exception package on its own i think for readability i make exception handling more explicit.


It also helps to think of components and subsystems other than to think of client, server, exception, etc. package splitting.

i don't think that exception package seperation disagrees with subsystem/component ordering.


That way you could add the one package to your project and use my utilities. I think of that as goal == reuse.

I don't quite get this. if i am sharing libraries usually i anyway put the whole hierachy into a seperate .jar, so exceptions are included.

thanks again.
 
wood burning stoves
 
subject: exceptions in own package
 
Similar Threads
B&S: Unimplemented exceptions
Package for mandatory exceptions class
top level class access modifier woes
An easy class/object/importation question.
Keeping Exceptions Classes