[LANG] Exceptions & Lang 3.0

[Henri Yandell <fl...@gmail.com>]

So some grumbles about the exceptions, and wondering which are worth fixing.

1) All the exceptions are in lang.* rather than lang.exception.*. Now
that the subpackage is pretty empty, it's tempting to move the
exceptions themselves down there. Given that it's going to be a
different package (ie: lang3 not lang), this seems doable. Probably
best to only do it when trunk changes to lang3.

2) There's the complaint that Validate should use
NullArgumentException in some places. NullArgumentException itself is
a painful class for legacy - it embeds text directly into itself
making it less adaptable, though easier to use:

        super((argName == null ? "Argument" : argName) + " must not be null.");

This stops it being useable in Validate in which the user determines
the message; and also makes it a pain if anyone wants to use
NullArgumentException with their own text. I don't see any easy ways
to do this in such a way that the developer is clearly going to tell
that the String constructor argument has changed semantics - which
given that NullArgumentException exists to make a semantic point of
language makes me want to delete it altogether. It's already more
trouble than it's worth and people could roll back to using
IllegalArgumentException (closing LANG-52 as WONTFIX).

3) IllegalClassException. I think that, generally, this has been
replaced by generics. Again my urge is to delete and have the much
smaller use case of examples simply use IllegalArgumentException.

4) IncompleteArgumentException. The same problem of hardcoding text in
the message. Not feeling like it offers much to the user.

5) NotImplementedException does have hardcoded text, but it is in a
sufficiently optional version of the constructor.

Hen

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

Re: [LANG] Exceptions & Lang 3.0

[Paul Benedict <pb...@apache.org>]

I think NullArgumentException should be deprecated and removed. It is
becoming a best practice to use NPE for null arguments. Joshua Bloch
has produced two books containing such advice, and Google Collections
has gone this way too. By the way, it's because the JDK has set this
precedent.

Paul

On Mon, Jul 20, 2009 at 1:12 PM, Henri Yandell<fl...@gmail.com> wrote:
> Hi Stephen :)
>
> On Sun, Jul 19, 2009 at 11:35 AM, Stephen
> Colebourne<sc...@btopenworld.com> wrote:
>> Henri Yandell wrote:
>>>
>>> 1) All the exceptions are in lang.* rather than lang.exception.*. Now
>>> that the subpackage is pretty empty, it's tempting to move the
>>> exceptions themselves down there. Given that it's going to be a
>>> different package (ie: lang3 not lang), this seems doable. Probably
>>> best to only do it when trunk changes to lang3.
>>
>> I'd prefer to see the subpackage removed and the exception classes stay put.
>
> So moving ExceptionUtils up. I'm fine with that too.
>
>>> 2) NullArgumentException
>>
>> I've never quite convinced myself that [lang] can make this exception work
>> alone. However, I suspect that some teams will have used it widely in their
>> own standards. As such, I'd suggest keeping it in [lang], but continuing to
>> not use it - closing LANG-52 as WONTFIX.
>
> How about putting in the backcompat?
>
>>> 3) IllegalClassException. I think that, generally, this has been
>>> replaced by generics. Again my urge is to delete and have the much
>>> smaller use case of examples simply use IllegalArgumentException.
>>
>> There are still plenty of places where generics doesn't work (or where you
>> need to check for invalid values passed in by raw types.
>
> Fair enough.
>
>>> 4) IncompleteArgumentException. The same problem of hardcoding text in
>>> the message. Not feeling like it offers much to the user.
>>>
>>> 5) NotImplementedException does have hardcoded text, but it is in a
>>> sufficiently optional version of the constructor.
>>
>> In general, I'd keep these exceptions. But if they are to be removed, I'd
>> try and remove all of them.
>
> Happy on the #5; #4... I don't like the hardcoded text and can't think
> how to clearly fix things without a name change. Also doesn't seem as
> valuable as others.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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

Re: [LANG] Exceptions & Lang 3.0

[Henri Yandell <fl...@gmail.com>]

On Mon, Jul 20, 2009 at 12:24 PM, Stephen
Colebourne<sc...@btopenworld.com> wrote:
> Henri Yandell wrote:
>>>>
>>>> 2) NullArgumentException
>>
>> How about putting in the backcompat?
>
> I would be fine with all four going in the backcompat.

Agreed. I've gone ahead and done that.

Hen

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

Re: [LANG] Exceptions & Lang 3.0

[Stephen Colebourne <sc...@btopenworld.com>]

Henri Yandell wrote:
>>> 2) NullArgumentException
> 
> How about putting in the backcompat?

I would be fine with all four going in the backcompat.

Stephen

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

Re: [LANG] Exceptions & Lang 3.0

[Henri Yandell <fl...@gmail.com>]

Hi Stephen :)

On Sun, Jul 19, 2009 at 11:35 AM, Stephen
Colebourne<sc...@btopenworld.com> wrote:
> Henri Yandell wrote:
>>
>> 1) All the exceptions are in lang.* rather than lang.exception.*. Now
>> that the subpackage is pretty empty, it's tempting to move the
>> exceptions themselves down there. Given that it's going to be a
>> different package (ie: lang3 not lang), this seems doable. Probably
>> best to only do it when trunk changes to lang3.
>
> I'd prefer to see the subpackage removed and the exception classes stay put.

So moving ExceptionUtils up. I'm fine with that too.

>> 2) NullArgumentException
>
> I've never quite convinced myself that [lang] can make this exception work
> alone. However, I suspect that some teams will have used it widely in their
> own standards. As such, I'd suggest keeping it in [lang], but continuing to
> not use it - closing LANG-52 as WONTFIX.

How about putting in the backcompat?

>> 3) IllegalClassException. I think that, generally, this has been
>> replaced by generics. Again my urge is to delete and have the much
>> smaller use case of examples simply use IllegalArgumentException.
>
> There are still plenty of places where generics doesn't work (or where you
> need to check for invalid values passed in by raw types.

Fair enough.

>> 4) IncompleteArgumentException. The same problem of hardcoding text in
>> the message. Not feeling like it offers much to the user.
>>
>> 5) NotImplementedException does have hardcoded text, but it is in a
>> sufficiently optional version of the constructor.
>
> In general, I'd keep these exceptions. But if they are to be removed, I'd
> try and remove all of them.

Happy on the #5; #4... I don't like the hardcoded text and can't think
how to clearly fix things without a name change. Also doesn't seem as
valuable as others.

Hen

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

Re: [LANG] Exceptions & Lang 3.0

[Stephen Colebourne <sc...@btopenworld.com>]

Henri Yandell wrote:
> 1) All the exceptions are in lang.* rather than lang.exception.*. Now
> that the subpackage is pretty empty, it's tempting to move the
> exceptions themselves down there. Given that it's going to be a
> different package (ie: lang3 not lang), this seems doable. Probably
> best to only do it when trunk changes to lang3.

I'd prefer to see the subpackage removed and the exception classes stay put.

> 2) NullArgumentException

I've never quite convinced myself that [lang] can make this exception 
work alone. However, I suspect that some teams will have used it widely 
in their own standards. As such, I'd suggest keeping it in [lang], but 
continuing to not use it - closing LANG-52 as WONTFIX.

> 3) IllegalClassException. I think that, generally, this has been
> replaced by generics. Again my urge is to delete and have the much
> smaller use case of examples simply use IllegalArgumentException.

There are still plenty of places where generics doesn't work (or where 
you need to check for invalid values passed in by raw types.

> 4) IncompleteArgumentException. The same problem of hardcoding text in
> the message. Not feeling like it offers much to the user.
> 
> 5) NotImplementedException does have hardcoded text, but it is in a
> sufficiently optional version of the constructor.

In general, I'd keep these exceptions. But if they are to be removed, 
I'd try and remove all of them.

Stephen

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