commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] right way to throw IndexOutOfBoundsException?
Date Tue, 09 Aug 2011 16:34:54 GMT
Le 08/08/2011 23:43, Gilles Sadowski a écrit :
>>>>>>> [...]
>>>>>>>>> Cases such as this would fall in the "illegal argument"
>>>>>>>>> category.
>>>>>>>>> Thus:
>>>>>>>>>     throw new OutOfRangeException(index, 0, parameters.length);
>>>>>>>>> or, to get a more detailed message,
>>>>>>>>>     OutOfRangeException e = new OutOfRangeException(index,
>>>>>>>>> parameters.length);
>>>>>>>>>     e.addMessage(INDEX, index);
>>>>>>>>>     throw e;
>>>>>>>>> Of course, "OutOfRangeException" cannot inherit from
>>>>>>>>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
>>>>>>>> I thought about that, but would prefer to throw
>>>>>>>> ArrayIndexOutOfBoundsException because that is really what
>>>>>>>> going
>>>>>>>> on and I would prefer to throw the standard exception.
>>>>>>>> Ideally, I
>>>>>>>> would like to throw that with a message reporting the value
>>>>>>>> and the
>>>>>>>> length of the array.  So, there are three choices:
>>>>>>>> 0) throw AIOB with no message
>>>>>>>> 1) subclass and throw with localized message - my suggestion
>>>>>>>> above
>>>>>>>> 2) OutOfRangeException
>>>>>>>> I like 1) the best and since we have decided to deprecate
>>>>>>>> MathRuntimeException, note that it applies to all of the
>>>>>>>> standard exceptions generated by MathRuntimeException's
>>>>>>>> createXxx
>>>>>>>> methods that have not yet been subclassed.  I think we should
>>>>>>>> follow
>>>>>>>> the generally accepted practice to favor standard exceptions,
>>>>>>>> that means we are going to have to create wrappers for all
>>>>>>>> that we
>>>>>>>> use.  I am willing to help with this.  In this case, I will
>>>>>>>> go ahead
>>>>>>>> and add the MathArrayIndexOutOfBoundsException that will
be an
>>>>>>>> ArrayIndexOutOfBoundsException if others are OK with this.
>>>>>>>> Note
>>>>>>>> that doing this will allow us to handle situations where
>>>>>>>> is not
>>>>>>>> appropriate (essentially why AIOB does not itself extend
>>>>>>> As I understand it, AIOB is a low-level exception that is
>>>>>>> thrown by the JVM
>>>>>>> checking an array access:
>>>>>>> ---CUT---
>>>>>>>     i = 3;
>>>>>>>     double a = arr[i]; //<--- can throw AIOB
>>>>>>> ---CUT---
>>>>>>> However, I don't see how a user code can be similar to this:
>>>>>>> When you check
>>>>>>> the index in your above code, you didn't try to access the
>>>>>>> array yet. You've
>>>>>>> detected that it won't work because the index value is "out of
>>>>>>> range", thus,
>>>>>>> "illegal".
>>>>>> When we are about to access an array, we can perform the
>>>>>> check.  We
>>>>>> can either just allow the JVM to throw the RTE (essentially my
>>>>>> option 0) above) or provide some more context info to the user (my
>>>>>> option 1) or throw an entirely different exception (option 2).  It
>>>>>> is good to throw some kind of AIOB when that is in fact what is
>>>>>> going on, as it provides more context info than just "something is
>>>>>> out of range" (OutOfRangeException).
>>>>> As shown above, you can add as many items of context information
>>>>> as you want
>>>>> with the exception context. The example I've suggested above
>>>>> will create a
>>>>> message that will print something like:
>>>>>     OutOfRangeException: 3 out of [0, 2] range: index (3)
>>>>> I find this quite clear; but we can even add another
>>>>> "LocalizedFormats" like
>>>>> "ARRAY_INDEX" if you really need the above to read:
>>>>>     OutOfRangeException: 3 out of [0, 2] range: array index (3)
>>>>> However, the crux of my point is that the "array" part is an
>>>>> implementation
>>>>> detail. A user should not care that a sequence of data is stored
>>>>> in an array
>>>>> of primitives or in a "List" or a CM's "RealVector". The real
>>>>> info is that
>>>>> the index used to access the data must fall within a range; if
>>>>> not, it is
>>>>> "out of range".
>>>>> Then, what I was saying in the previous post is that we should
>>>>> not throw
>>>>> AIOB because we are not the JVM. In Java, that exception is a
>>>>> *result* of
>>>>> "calling" the [] operator. Your test happens before calling it;
>>>>> and an
>>>>> "OutOfRangeException" is as accurate as necessary but not more
>>>>> (so as not to
>>>>> leak about the internals of a class).
>>>> I can see that we are not going to agree on this.  I prefer standard
>>>> exceptions and it is generally accepted best practice to favor
>>>> them.  To say that only the JDK should throw JDK RTEs is silly,
>>>> IMO.  We are going to have the same problem with ConcurrentMod, IO,
>>>> EOF and the others currently created by MathRuntimeException.  Are
>>>> we going to try to shoehorn every use of any of these into some kind
>>>> of "some number too small" or other special [math] exceptions?  What
>>>> do others think about this?
>>> Well, I basically gave up on exceptions :-(
>>> Here are my views, but I would not enforce them anymore on anybody.
>>> I consider JDK exceptions could be used, and that we needed the
>>> localization (I know the view of everyone on this, so don't argue
>>> again). this was the reason for the createXxx exception, which had
>>> signatures corresponding to standard exceptions, and did subclass
>>> them with anonymous classes that override the JDK standard
>>> getMessage and getLocalizedMessage methods. This way, we combined
>>> both needs.
>> Well, I agree with your views and I am proposing that as a
>> compromise, we simply replace the createXxx methods in
>> MathRuntimeExceptions with exceptions like MathArithmeticException,
>> MathIllegalStateException, etc.
> This is done already!!!
>>   I am proposing in this case to add
>> MathArrayIndexOutOfBoundsException (extending AIOB so you can
> I do not understand why, in other circumstances, you are against propagating
> low-level error conditions ("number too small" being your favorite example)
> but here you find no problem exposing an implementation detail ("array")...
>> advertise the real thing) and I will even volunteer to fill in the
>> remaining ones from createXxx so we don't have to argue about this
>> any more.
> OK, I see that you just *like* antiques.
> So let's say that you will create as many exceptions as you deem nice
> (although one of the first conditions *I* had been set was to avoid a
> bloated exception package...).  I give up arguing all over again.
> To definitely close the exception debate, can we now set to resolve the
> issue of deprecating the (old) "MathRuntimeException" and "MathException"
> classes and purge all checked exceptions? These are the things which really
> matter and which I insist on keeping from the string of previous
> compromises.

Yes (but consider it non-binding).


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

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

View raw message