commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From _matthewHawthorne <mhawtho...@alumni.pitt.edu>
Subject RE: [lang] Some suggested exception additions.
Date Tue, 13 May 2003 17:23:51 GMT
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


Mime
View raw message