commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [lang] Some suggested exception additions.
Date Wed, 14 May 2003 05:44:25 GMT
_matthewHawthorne wrote:
> (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>
>

I am just learning my way around commons-lang; but for what it's worth 
here is how it looks to me.  I see the "commons.lang.exception.std" 
construct as "inside out".  If what is now commons.lang.exception is 
really, commons.lang.exception.nestable then putting something that is 
logically commons.lang.exception into "commons.lang.exception.std" 
because it does not fit with the current contents of 
commons.lang.exception makes no sense to me.  If we want to leave 
commons.lang.exception as is, then I would vote for putting the more 
generic exception extensions (above) into commons.lang.  If this results 
in commons.lang getting bloated with exception classes, then 
commons.lang.exception can be refactored. Just MHO.

Phil

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




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