commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] Some suggested exception additions.
Date Wed, 14 May 2003 22:16:03 GMT
I haven't commented on this until now... Personally, it makes more sense for
me to see these exceptions in the lang.exception package. They are
exceptions! But I'm not going to block them being in the root.

Stephen

----- Original Message -----
From: "Gary Gregory" <ggregory@seagullsw.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Sent: Wednesday, May 14, 2003 8:15 PM
Subject: RE: [lang] Some suggested exception additions.


>
"1)NullArgumentException,IncompleteArgumentException,IllegalClassException,a
> nd NotImplementedException
>
> are ok to go into lang"
>
> +1
>
> "2) Should UnhandledException go into lang or lang.exception?"
>
> I could see from a big picture POV that the whole lang.exception package
is
> "temporary" until the world standardizes on 1.4 (which will be no time
> soon). So I'll stop haggling on this detail and +1 the whole lot for
.lang.
>
> We can call this down-package dependency a temporary quirk.
>
> Gary
>
> -----Original Message-----
> From: _matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu]
> Sent: Wednesday, May 14, 2003 7:43 AM
> To: Jakarta Commons Developers List
> Subject: RE: [lang] Some suggested exception additions.
>
> UnhandledException is a shortcut for...
>
> try {
>
> } catch (IOException ex) {
> throw new RuntimeException(ex.toString());
> //or throw new IllegalStateException(ex.toString());
> }
>
> So, I don't have a problem with putting it in lang.exception... it is a
> utility exception, kind of.  But on the other hand, I still see it as a
> language extension... in a way, it converts a checked exception into an
> unchecked one.  I understand your dislike of lang depending on
> lang.exception... but since this dependency is only caused by the need
> for NestableException, would nestable exceptions in lang.* be ok if we
> were using java 1.4?
>
> So it seems that
>
>
1)NullArgumentException,IncompleteArgumentException,IllegalClassException,an
> d NotImplementedException
>
> are ok to go into lang
>
> but there is 1 remaining question...
>
> 2) Should UnhandledException go into lang or lang.exception?
>
>
>
>
> On Wed, 2003-05-14 at 18:16, Gary Gregory wrote:
> > Thank you for the clarification.
> >
> > (1) IllegalArgumentException subclasses
> >
> > Oops, my misunderstanding, sorry.
> >
> > I had the 1.4 exceptions in the back of my mind and the features
provided
> in
> > ..lang.exceptions. I kept on thinking that any new lang exception would
be
> in
> > the 1.4 style (holding on to an exception). This needs not be the case I
> see
> > now.
> >
> > Just for completeness I'll just make the reverse of a previous comment:
> > Since java.lang.IllegalArgumentException is subclassed, you cannot catch
> an
> > exception and throw a IllegalArgumentException subclass with the caught
> > exception preserved (as you would be able to under a "clean" 1.4 setup).
> >
> > Unless of course we think this is important and create a slot in the
> > IllegalArgumentException subclasses.
> >
> > (2) Packages
> > "UnhandledException extends
> > org.apache.commons.lang.exception.NestableRuntimeException"
> >
> > I am not sure I like a .lang class extending a .lang.sub-package class
but
> I
> > am not sure what to do about it. It is fine when a package depends on
> > another at the same level or up. Would it be too odd to have this
> exception
> > in .lang.exception?
> >
> > Since all the other Exceptions extend java.lang, putting them in our
.lang
> > is ok with me :-)
> >
> > Gary
> >
> > -----Original Message-----
> > From: _matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu]
> > Sent: Wednesday, May 14, 2003 6:33 AM
> > To: Jakarta Commons Developers List
> > Subject: RE: [lang] Some suggested exception additions.
> >
> > Just to clarify:
> >
> > NullArgumentException,IllegalClassException,IncompleteArgumentException
> > extend
> > java.lang.IllegalArgumentException
> >
> > NotImplementedException
> > extends
> > java.lang.UnsupportedOperationException
> >
> > UnhandledException
> > extends
> > org.apache.commons.lang.exception.NestableRuntimeException
> >
> > All of these, in some way or another, extend RuntimeException, so
> > try/catch blocks weren't really a consideration for me.  I didn't expect
> > any of them to be caught...
> >
> > (This may be out of scope for this discussion, but I only catch
> > RuntimeExceptions at the absolute root of a gui or server app, and I
> > usually catch Throwable, so I can at least log it)
> >
> > In my unit tests, if an exception is expected, I just catch
> > IllegalArgument, I don't worry about catching the more specific types.
> > I'm not sure if this is a good practice, or if it is just lazyness.
> >
> >
> >
> >
> > On Wed, 2003-05-14 at 16:53, Henri Yandell wrote:
> > > On Wed, 14 May 2003, Gary Gregory wrote:
> > >
> > > > "Despite my description, I don't know if I agree that these
exceptions
> > serve
> > > > a purpose different from other types of exceptions."
> > > >
> > > > Strictly speaking I agree with you. There is a subtle point that I
> keep
> > on
> > > > loosing track of when I think of these Exceptions: They are not 1.4
> > based in
> > > > the sense that the new NullArgumentException does not subclass
> > java.lang.
> > > > IllegalArgumentException. So I have to catch both
> NullArgumentException
> > and
> > > > IllegalArgumentException and not just more generically
> > > > IllegalArgumentException.
> > > >
> > > > Maybe one day we'll have a >=1.4 based commons where
> > NullArgumentException
> > > > simply subclasses java.lang.IllegalArgumentException. That'll be
> _years_
> > > > from now... ;-)
> > >
> > > Why not subclass IllegalArgumentException? It was in 1.0. I don't
> > > understand.
> > >
> > > Hen
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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