commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [lang] Some suggested exception additions.
Date Tue, 13 May 2003 21:46:06 GMT

I'm going to start with the belief that exceptions belong with their areas
of use and not in a central exception package, just in case there are any
believers in that out there:

On 13 May 2003, _matthewHawthorne wrote:

> After looking at the current location of exceptions in commons-lang...
>
> org.apache.commons.lang
> 	SerializationException

Owned by SerializationUtils.

> org.apache.commons.lang.exception
> 	NestableError
> 	NestableException
> 	NestableRuntimeException

Part of the exception packages functionality.

> org.apache.commons.lang.functor
> 	ExecutorException
> 	FactoryException
> 	PredicateException
> 	TransformerException

Functor based exceptions.

> org.apache.commons.lang.reflect
> 	ReflectionException

Reflection based exception.

> 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.

Agreed.

> 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.

Avoiding tons of classes in the base package is obviously a pretty
important thing to manage in the long term for Lang. Then again, I think
you're right that your exceptions are not necessarily lang.exception, just
because they have the same name.

lang.exception.std [or some such] is one option, but it's quite deep.

> I belive this is the reason why (for example)
> reflect.ReflectionException isn't in the lang.exception package.
>
> Any thoughts?

Options seem to be:

lang

  pro:  simple. people will reuse easily and it will feel lang like.
  con:  scopes poorly if we add lots more. Gets in the way of SerializationException.

lang.exception
  pro:  scopes better, also feels to be a good placement, as with above
  con:  gets in the way of other exception stuff, making it harder to see

lang.exception.std
  pro:  focused and tight
  con:  harder to find. stupid name 'std'

lang.stdexception
  pro:  easier to find. focused.
  con:  stupiderer name. bloats the package education.

Anyone got any others? Anyone got any preferences?

I'm torn between lang.* and lang.exception.std.

Hen

> 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
View raw message