Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

exceptions in own package

 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic