commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject Re: [commons]NPE or IAE?
Date Wed, 21 Aug 2002 22:35:20 GMT
>Having said all that, if commons is eventually to create a core.jar file,
>then really the exception handling should be consistent across it. Since
>[collections] is fixed on NPE, I reckon [io], [lang] and [pattern] must
>follow suit.

Now, to that I must raise an InvalidArgumentObjection.

It is beneficial with consistent exception handling, yes. But collections are tied to SUN
contracts, which makes it a special case. What if the core.jar was to include another API
that had different exception handling due to its ties with some other contract? Or included
a component with old legacy from another projects that donates its code to commons?

I am not looking for a handling principle that stands because of some special case, I am looking
for the principle that is working for _commons_. The guide that _commons_ fall back on, if
there are no special rules attached to some particular component due to some ties (like adherence
to a non-commons contract, or backwards compatibility with a contributing project of some

What should we choose when we can choose, that is. Not what we have to choose because we have
to, due to circumstances outside of commons control. In reality, I think we have to live with
different handling mechanisms (and that is not difficult, but rather the normal situation).

This is not said against using NPE:s, but against the argument. IAE only, or NPE and IAE,
whatever, but what are the arguments for and against if we only have to see to ourselves?
What do _we_ prefer?


0733 - 99 99 17

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message