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?
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.
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
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.
Joined: Dec 29, 2005
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.