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.