This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

orgazine the packages

Posted by Raghu Havaldar on May 05, 1999 at 11:12 AM

> > I was very excited to see your article about exceptions on the
> > JavaWorld site. I have been putting together a coding standard.
> > As with most other I have come across on my web searches, mine
> > is primarily based on JavaSoft's standards. No where have I
> > seen a good standard dealing with exceptions. The problem I
> > see is that on large projects most exceptions that developers
> > define are fairly simple with two constructors, one that takes
> > no args and on that takes a String. Say I have a project has
> > two packages that a totally seperate from each other but both
> > do some sort of parsing. I think most developers would tend
> > to unknowingly define a ParseException in both packages which
> > leads to confusion and does not promote code reuse. I was
> > thinking that it might be a good idea to create an exception
> > package where all exceptions are defined. Then when a developer
> > needs to define a new exception he first looks in this package
> > to see if there is anything he can use and then if not defines
> > one there. The downfall of this approach is that instead of
> > just being able to deliver one package if you also have to
> > deliver this backage package with several exceptions that your
> > package doesn't need. What are your thoughts? Have you seen
> > any good standards?
> >
> My thought on this is that code reuse probably isn't that
> critical when all you are doing is creating a class that only
> has two constructors and no methods.

> One other reader submitted a comment saying that they thought
> inner classes were a convenient place to define exception types.
> In this way, the exception class is defined in the same class
> as the class that throws the exception. The trouble here is
> that two classes in the same package might even declare the
> same exception, and then the client would have to say
> Class1.ParseException and Class2.ParseException. Of course, I
> just said code reuse isn't that big of a deal, but the
> extra typing and potential confusion might be a more
> significant problem.

> I think my own feeling is that I would tend towards the
> approach that seems to be taken by the Java API. Exceptions
> that will be thrown by classes in each package are defined
> in that package (as top-level, unnested (not inner) classes).
> So within a certain package, there will be just one
> ParseException. But across two packages there might be two
> ParseExceptions. I agree that having two different
> ParseExceptions could cause confusion, so this approach isn't
> perfect.

> I'd be interested in hearing other people's opinions on this
> one. It might also make a good opinion survey for JavaWorld.

> bv

I would tend to lean towards the idea to have both the packages (doing parsing) in one package (super-package if u will). The ParseException would then be defined in this super-package, along with any common classes and interfaces. With this approach, both the sub-packages doing parsing can utilize the ParseException.

The above approach might not work in all cases: imagine have two subsystems trying to use a family of parse exceptions. Assuming that the two subsytems are classified in packages p1 and p2. Define a package - 'parse' that contains commong parsing classes and interfaces. This package would also contain the ParseException and the family of exceptions w.r.t to parsing. This allows re-use of the parse package, along with the corresponding exception family.

Any comments.....

Raghu