commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [lang] Some suggested exception additions.
Date Wed, 14 May 2003 14:35:28 GMT
I know that the .lang package choice has already gotten a "+1" but I think
names are important and I could see this batch of classes growing larger
easily in the future, so I'd like to continue this packaging discussion.

Ah, thanks, this clarifies the picture for me succinctly in one shot, so, to
paraphrase and abbreviate, the set of classes (not yet a package but could

"Provides descriptive, explicit error messages". 

So we are talking about formalizing common error messages into classes. Then
I could see one of:

   "Provides exception classes to formalize commonly used message patterns."

   "Represents an exception vocabulary to formalize commonly used exception
message patterns"

This gives this group of classes a clear purpose different from any other
kind of exceptions, especially those that are tied to specific behavior
(like Serialization) or carry extra error information.


-----Original Message-----
From: _matthewHawthorne [] 
Sent: Wednesday, May 14, 2003 2:11 AM
To: Jakarta Commons Developers List
Subject: RE: [lang] Some suggested exception additions.

On Wed, 2003-05-14 at 06:30, Gary Gregory wrote:
> _If_ we do not want to put a growing batch of Exception classes in .lang:
> I am not in favor of a "std" package namde since the package does not
> implement or define a "Standard". Perhaps the word "standard" can be used
> the phrase "the standard application exception utilities we use" but that
> does not ring right to me. This might just be my ears that need
> I am thinking of what the package comment would read like, which in turn
> would help defining the package name. 
> Could the author of the new classes define the batch of classes in one or
> two sentences?

First off, I would define the classes as follows:

Exceptions which represent more specialized versions of their existing
Java couterparts, with the purpose of providing descriptive, explicit
error messages.


I agree with Gary that these classes do not define a standard, so the
std package name may be a misleading name.  In a sense, I do see them as
"language extensions", since they all represent very common situations
that I encounter while developing.  That's part of the reason why I see
them fitting in lang.*, but I acknowledge the need to keep that package
from getting overcrowded.  

I have never seen a separate package dedicated to exceptions, as we've
already discussed, they are usually found in the package which defines
their domain.  In the case of such generic exceptions, the domain would
seem to be *.lang or *.util.

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message