commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang] Some suggested exception additions.
Date Wed, 14 May 2003 06:35:27 GMT
It is not clear to me what is best or the "least worse" if you can say such
a thing ;-). To me:

1) org.apache.commons.lang
Pro: crowds .lang but seems "least worse".

2) org.apache.commons.lang.exception.std
I do not like this one. Please see my previous message for my comments on
this one.

3) org.apache.commons.lang.<choose a better package name>
Ideally, I would have the new classes in .lang.ex and the current
.lang.exception in .lang or perhaps .lang.nested.

It is starting to sound like we'll end up putting them in .lang but I think
it is a bit odd to have classes in a package extend classes from a
sub.package. But... in the long long run, when JRE < 1.4 are no longer
supported you will not need .lang.exception and the Exceptions in .lang can
simply be changed to extend 1.4 Exceptions, which would be nice.

Round and round...

Gary

-----Original Message-----
From: _matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu] 
Sent: Tuesday, May 13, 2003 5:47 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] Some suggested exception additions.

(So, the question has become...)

The following exceptions:

IllegalClassException
IncompleteArgumentException
NullArgumentException
NotImplementedException
UnhandledException

Should be placed in which package?

1) org.apache.commons.lang

2) org.apache.commons.lang.exception.std

3) org.apache.commons.lang.<choose a better package name>





On Wed, 2003-05-14 at 00:03, Gary Gregory wrote:
> I see your points. I initially leaned towards a not .lang choice but for
> lang.exception or .lang.something. But #2, this leads to some interesting
> things, here is my thinking: When I look at .lang (not sub-packages) I see
> WRT Exceptions, direct extensions of java.lang features, which should be
> very basic. SerializationException being a good example.
> 
> When I look at the nice new classes we have here, I see "application
> utilities" more than "language extensions", which, to me means that they
> should be in one atomic unit -> one package. <sidenote>One other item here
> that I am not fond of is that a .lang class (SerializationException)
extends
> a class in a sub-package lang.exception.NestableRuntimeException. That
seems
> a little odd but I can live with it.</sidenote>
> 
> So, if I had my way I would put the new classes in .lang.exception or
> ..lang.exception.something (which I would rename .lang.ex 'cause I am poor
> typist and its OK to abbreviate package names ;-)
> 
> Actually, after reading the other reply (from Henri) to this message I
think
> that we really should not overuse namespaces, which makes me think of
> putting it all in .lang.ex BUT then I really like the guideline that says
> that packages can be considered as atomic deliverable units and be self
> contained and in that sense I like being able to separate .lang.ex from
the
> "exception application utilities". So (hopping that I am boring everyone
> with this) I would go for keeping .lang.ex as small and clean as possible
> and adding .lang.ex.app (lame name) which provide Exception application
> utilities. Should these exceptions be delivered in two packages, one based
> on lang.ex, one on 1.4 exceptions?
> 
> Gary
> 
> -----Original Message-----
> From: _matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu] 
> Sent: Tuesday, May 13, 2003 10:24 AM
> To: Jakarta Commons Developers List
> Subject: RE: [lang] Some suggested exception additions.
> 
> After looking at the current location of exceptions in commons-lang...
> 
> org.apache.commons.lang
> 	SerializationException
> 
> org.apache.commons.lang.exception
> 	NestableError
> 	NestableException
> 	NestableRuntimeException
> 			
> org.apache.commons.lang.functor
> 	ExecutorException
> 	FactoryException
> 	PredicateException
> 	TransformerException
> 
> org.apache.commons.lang.reflect
> 	ReflectionException
> 
> 
> It doesn't seem that an exception such as NullArgument or NotImplemented
> naturally fits in the lang.exception package, since that package seems
> to contain utilities for working with exceptions, or generic exceptions
> meant to be extended, not the exceptions themselves.
> 
> This is why I suggested that the new exceptions I'm submitting should go
> in the base commons.lang package, since that seems to be the most
> logical domain.
> 
> I belive this is the reason why (for example)
> reflect.ReflectionException isn't in the lang.exception package.
> 
> Any thoughts?
> 				
> 
> 
> On Tue, 2003-05-13 at 20:14, Gary Gregory wrote:
> > Well, we already have a released .lang.exception package, so it should
go
> in
> > there unless you want to start a discussion on repackaging.
> > 
> > Gary
> > 
> > -----Original Message-----
> > From: _matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu] 
> > Sent: Monday, May 12, 2003 3:28 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: RE: [lang] Some suggested exception additions.
> > 
> > Ok, I have the exceptions, test cases, and documentation near
> > completion.  Here are a few questions before I submit the patch:
> > 
> > 1) What package should I put them in?  org.apache.commons.lang,
> > org.apache.commons.lang.exception, org.apache.commons.lang.util, or any
> > other possibilities?  I prefer the first choice.
> > 
> > 2) I have added the ability to customize the error messages where
> > possible, but it is difficult with exceptions such as NullArgument,
> > which has a constructor of the form:
> > 
> > NullArgumentException(String argName)
> > 
> > What would be the preferred way to allow customization?  Are we sure
> > that customization is required in this situation?  One option would be
> > 
> > NullArgumentException(String msg, boolean override)
> > 
> > which would use the flag to decide whether the String was an argument
> > name or the full message.  But, for some reason, this doesn't seem clean
> > to me. In a sense, it defeats the purpose of the exception, which was to
> > standardize common error messages.  
> > 
> > Let me know your thoughts, I want these exceptions to be useful for
> > everyone.
> > 
> > 
> > 
> > 
> > 
> > On Sun, 2003-05-11 at 17:04, Henri Yandell wrote:
> > > I like them all as well. I'm wary of the ones that don't extend
another
> > > Exception as I think extending an existing JVM exception is a nice
idea.
> > > Could IncompleteArgument extend IllegalArgument? Also, could the
concept
> > > of an incomplete argument be defined further?
> > > 
> > > I think IllegalClass could also extend IllegalArgument as it seems
> mainly
> > > useful in the argument context, but there could be contexts I'm
missing.
> > > 
> > > I also assume that the constructors for each one do allow me to set a
> > > message if I am not happy with the default one?
> > > 
> > > Hen
> > > 
> > > On Sun, 11 May 2003, Steven Caswell wrote:
> > > 
> > > > These all look interesting to me. If there are no objections from
> > others,
> > > > I'll be happy to commit them if you'd like to submit them. Please
> > include
> > > > the Apache license stuff at the top of the sources. Simple test
cases
> > would
> > > > also be welcome, as well as javadocs.
> > > >
> > > >
> > > > Steven Caswell
> > > > steven@caswell.name
> > > > a.k.a Mungo Knotwise of Michel Delving
> > > > "One ring to rule them all, one ring to find them..."
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: _matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu]
> > > > > Sent: Saturday, May 10, 2003 7:31 PM
> > > > > To: Jakarta Commons Developers List
> > > > > Subject: [lang] Some suggested exception additions.
> > > > >
> > > > >
> > > > > I use the following exceptions frequently, is there any
> > > > > interest in including them in [lang]?
> > > > >
> > > > > ================================
> > > > >
> > > > > - IllegalClassException
> > > > > 	Thrown when an object is an instance of an unexpected class.
> > > > >
> > > > > 	Useful for implementations of interfaces that specify Object
> as
> > > > > 	parameter type, but require a more specific class.
> > > > >
> > > > > 	constructor:
> > > > > 	IllegalClassException(Class expected, Class found)
> > > > >
> > > > > - IncompleteArgumentException
> > > > > 	Thrown to indicate an incomplete argument to a method.
> > > > >
> > > > > - NotImplementedException
> > > > > (extends java.lang.UnsupportedOperationException)
> > > > >
> > > > > 	Thrown to indicate that a method has not been implemented.
> > > > >
> > > > > 	Useful because it informs the caller of the
> > > > > implementation 	class, if
> > > > > it is not directly known.
> > > > >
> > > > > 	constructor:
> > > > > 	NotImplementedException(Class clazz)
> > > > >
> > > > > - NullArgumentException (extends
java.lang.IllegalArgumentException)
> > > > > 	Thrown to indicate that a method argument was null and
> > > > > should 	not have
> > > > > been.
> > > > >
> > > > > 	constructor:
> > > > > 	NullArgumentException(String argName)
> > > > >
> > > > > - UnhandledException (extends NestableRuntimeException)
> > > > > 	Generic nestable wrapper, useful when a checked
> > > > > Exception is 	consumed
> > > > > and thrown as a RuntimeException
> > > > >
> > > > > 	constructor:
> > > > > 	UnhandledException(Throwable cause)
> > > > >
> > > > > ================================
> > > > >
> > > > > One of the main benefits is the elimination of writing
> > > > > repetitive error messages
> > > > >
> > > > > for example:
> > > > > 	throw new IllegalArgumentException("xxx cannot be null")
> becomes
> > > > > 	throw new NullArgumentException("xxx");
> > > > >
> > > > >
> > > > > Any suggestions or thoughts?
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > > >
> > > 
> > > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

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