You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2011/08/08 07:47:41 UTC

[math] right way to throw IndexOutOfBoundsException?

I was about to do this:
throw MathRuntimeException.createArrayIndexOutOfBoundsException(
                    LocalizedFormats.OUT_OF_RANGE_SIMPLE, index, 0,
parameters.length);

but remembered that this is now deprecated.  Do I need to add a
MathArrayIndexOutOfBoundsException extending the JDK exception and
then throw that directly?  

Phil

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


Re: [math] right way to throw IndexOutOfBoundsException?

Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Mon, Aug 08, 2011 at 12:25:00PM -0700, Phil Steitz wrote:
> On 8/8/11 12:03 PM, Gilles Sadowski wrote:
> > Hi.
> >
> >>> [...]
> >>>>> 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, 0, parameters.length);
> >>>>>   e.addMessage(INDEX, index);
> >>>>>   throw e;
> >>>>>
> >>>>>
> >>>>> Of course, "OutOfRangeException" cannot inherit from both
> >>>>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
> >>>> I thought about that, but would prefer to throw
> >>>> ArrayIndexOutOfBoundsException because that is really what is 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 the
> >>>> MathRuntimeException, note that it applies to all of the other
> >>>> 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, so
> >>>> 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 IAE is not
> >>>> appropriate (essentially why AIOB does not itself extend IAE).
> >>> 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,

You are again starting to caricature my viewpoint.
I think that it is silly to try to mimic everything that was designed in the
early days (or before) of Java, and is now largely dismissed by Java experts.

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

It is so strange that on the one hand, you insist on following what you call
the standard practice (e.g. copy/wrap/inherit/advertise the Java exceptions)
but on the other hand, the above example show that you want to do so in a
_non-standard_ way: you mimic Java *checked* exceptions (IO, EOF, etc.) with
unchecked ones!
Does that make more sense than radically depart from a legacy design and
have a new clean, minimal, unincumbered one?

> [...]


Gilles

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


Re: [math] right way to throw IndexOutOfBoundsException?

Posted by Luc Maisonobe <Lu...@free.fr>.
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, 0,
>>>>>>>>> parameters.length);
>>>>>>>>>     e.addMessage(INDEX, index);
>>>>>>>>>     throw e;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Of course, "OutOfRangeException" cannot inherit from both
>>>>>>>>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
>>>>>>>> I thought about that, but would prefer to throw
>>>>>>>> ArrayIndexOutOfBoundsException because that is really what is
>>>>>>>> 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 the
>>>>>>>> MathRuntimeException, note that it applies to all of the other
>>>>>>>> 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, so
>>>>>>>> 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 IAE
>>>>>>>> is not
>>>>>>>> appropriate (essentially why AIOB does not itself extend IAE).
>>>>>>> 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).

Luc

>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [math] right way to throw IndexOutOfBoundsException?

Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >>>>> [...]
> >>>>>>> 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, 0,
> >>>>>>> parameters.length);
> >>>>>>>    e.addMessage(INDEX, index);
> >>>>>>>    throw e;
> >>>>>>>
> >>>>>>>
> >>>>>>> Of course, "OutOfRangeException" cannot inherit from both
> >>>>>>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
> >>>>>> I thought about that, but would prefer to throw
> >>>>>> ArrayIndexOutOfBoundsException because that is really what is
> >>>>>> 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 the
> >>>>>> MathRuntimeException, note that it applies to all of the other
> >>>>>> 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, so
> >>>>>> 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 IAE
> >>>>>> is not
> >>>>>> appropriate (essentially why AIOB does not itself extend IAE).
> >>>>> 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.


Gilles

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


Re: [math] right way to throw IndexOutOfBoundsException?

Posted by Phil Steitz <ph...@gmail.com>.
On 8/8/11 12:55 PM, Luc Maisonobe wrote:
> Le 08/08/2011 21:25, Phil Steitz a écrit :
>> On 8/8/11 12:03 PM, Gilles Sadowski wrote:
>>> Hi.
>>>
>>>>> [...]
>>>>>>> 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, 0,
>>>>>>> parameters.length);
>>>>>>>    e.addMessage(INDEX, index);
>>>>>>>    throw e;
>>>>>>>
>>>>>>>
>>>>>>> Of course, "OutOfRangeException" cannot inherit from both
>>>>>>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
>>>>>> I thought about that, but would prefer to throw
>>>>>> ArrayIndexOutOfBoundsException because that is really what is
>>>>>> 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 the
>>>>>> MathRuntimeException, note that it applies to all of the other
>>>>>> 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, so
>>>>>> 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 IAE
>>>>>> is not
>>>>>> appropriate (essentially why AIOB does not itself extend IAE).
>>>>> 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.  I am proposing in this case to add
MathArrayIndexOutOfBoundsException (extending AIOB so you can
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.

Phil
>
> Once again, this are only my own views. Do what you want with them.
>
> Luc
>
>>
>> Phil
>>>
>>>
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>>
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: [math] right way to throw IndexOutOfBoundsException?

Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Mon, Aug 08, 2011 at 09:55:49PM +0200, Luc Maisonobe wrote:
> Le 08/08/2011 21:25, Phil Steitz a écrit :
> >On 8/8/11 12:03 PM, Gilles Sadowski wrote:
> >>Hi.
> >>
> >>>>[...]
> >>>>>>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, 0, parameters.length);
> >>>>>>   e.addMessage(INDEX, index);
> >>>>>>   throw e;
> >>>>>>
> >>>>>>
> >>>>>>Of course, "OutOfRangeException" cannot inherit from both
> >>>>>>"IllegalArgumentException" and "IndexOutOfBoundsException"...
> >>>>>I thought about that, but would prefer to throw
> >>>>>ArrayIndexOutOfBoundsException because that is really what is 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 the
> >>>>>MathRuntimeException, note that it applies to all of the other
> >>>>>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, so
> >>>>>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 IAE is not
> >>>>>appropriate (essentially why AIOB does not itself extend IAE).
> >>>>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.

At the cost of strange-looking code:
  throw new MathRuntime.createXxxException("some message", args);
instead of the cleaner:
  throw new XxxException(args);

All needs (detailed info + localization) are still covered by the "new"
(standard) way: This was the compromise we agreed on. But it is perpetually
being eroded!

> Once again, this are only my own views. Do what you want with them.

All I have asked for is to let a chance to the new design. If users complain
at the release of 3.0, then fine you'll go back to the old days, but it's
not fair to act as if nothing had been done for over one year.


Best,
Gilles

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


Re: [math] right way to throw IndexOutOfBoundsException?

Posted by Luc Maisonobe <Lu...@free.fr>.
Le 08/08/2011 21:25, Phil Steitz a écrit :
> On 8/8/11 12:03 PM, Gilles Sadowski wrote:
>> Hi.
>>
>>>> [...]
>>>>>> 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, 0, parameters.length);
>>>>>>    e.addMessage(INDEX, index);
>>>>>>    throw e;
>>>>>>
>>>>>>
>>>>>> Of course, "OutOfRangeException" cannot inherit from both
>>>>>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
>>>>> I thought about that, but would prefer to throw
>>>>> ArrayIndexOutOfBoundsException because that is really what is 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 the
>>>>> MathRuntimeException, note that it applies to all of the other
>>>>> 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, so
>>>>> 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 IAE is not
>>>>> appropriate (essentially why AIOB does not itself extend IAE).
>>>> 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.

Once again, this are only my own views. Do what you want with them.

Luc

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


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


Re: [math] right way to throw IndexOutOfBoundsException?

Posted by Phil Steitz <ph...@gmail.com>.
On 8/8/11 12:03 PM, Gilles Sadowski wrote:
> Hi.
>
>>> [...]
>>>>> 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, 0, parameters.length);
>>>>>   e.addMessage(INDEX, index);
>>>>>   throw e;
>>>>>
>>>>>
>>>>> Of course, "OutOfRangeException" cannot inherit from both
>>>>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
>>>> I thought about that, but would prefer to throw
>>>> ArrayIndexOutOfBoundsException because that is really what is 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 the
>>>> MathRuntimeException, note that it applies to all of the other
>>>> 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, so
>>>> 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 IAE is not
>>>> appropriate (essentially why AIOB does not itself extend IAE).
>>> 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?

Phil
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [math] right way to throw IndexOutOfBoundsException?

Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.

> > [...]
> >>> 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, 0, parameters.length);
> >>>   e.addMessage(INDEX, index);
> >>>   throw e;
> >>>
> >>>
> >>> Of course, "OutOfRangeException" cannot inherit from both
> >>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
> >> I thought about that, but would prefer to throw
> >> ArrayIndexOutOfBoundsException because that is really what is 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 the
> >> MathRuntimeException, note that it applies to all of the other
> >> 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, so
> >> 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 IAE is not
> >> appropriate (essentially why AIOB does not itself extend IAE).
> > 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).


Gilles

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


Re: [math] right way to throw IndexOutOfBoundsException?

Posted by Phil Steitz <ph...@gmail.com>.
On 8/8/11 10:01 AM, Gilles Sadowski wrote:
> On Mon, Aug 08, 2011 at 08:34:13AM -0700, Phil Steitz wrote:
>> On 8/7/11 11:38 PM, Gilles Sadowski wrote:
>>> On Sun, Aug 07, 2011 at 10:47:41PM -0700, Phil Steitz wrote:
>>>> I was about to do this:
>>>> throw MathRuntimeException.createArrayIndexOutOfBoundsException(
>>>>                     LocalizedFormats.OUT_OF_RANGE_SIMPLE, index, 0,
>>>> parameters.length);
>>>>
>>>> but remembered that this is now deprecated.  Do I need to add a
>>>> MathArrayIndexOutOfBoundsException extending the JDK exception and
>>>> then throw that directly?  
>>> Do we really want to subclass all Java exceptions?
>>> There was a discussion where I thought that we circumscribed all the types
>>> of problems that would need CM exceptions to sublcass the standard ones.
>>>
>>> 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, 0, parameters.length);
>>>   e.addMessage(INDEX, index);
>>>   throw e;
>>>
>>>
>>> Of course, "OutOfRangeException" cannot inherit from both
>>> "IllegalArgumentException" and "IndexOutOfBoundsException"...
>> I thought about that, but would prefer to throw
>> ArrayIndexOutOfBoundsException because that is really what is 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 the
>> MathRuntimeException, note that it applies to all of the other
>> 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, so
>> 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 IAE is not
>> appropriate (essentially why AIOB does not itself extend IAE).
> 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). 

Phil
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [math] right way to throw IndexOutOfBoundsException?

Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Mon, Aug 08, 2011 at 08:34:13AM -0700, Phil Steitz wrote:
> On 8/7/11 11:38 PM, Gilles Sadowski wrote:
> > On Sun, Aug 07, 2011 at 10:47:41PM -0700, Phil Steitz wrote:
> >> I was about to do this:
> >> throw MathRuntimeException.createArrayIndexOutOfBoundsException(
> >>                     LocalizedFormats.OUT_OF_RANGE_SIMPLE, index, 0,
> >> parameters.length);
> >>
> >> but remembered that this is now deprecated.  Do I need to add a
> >> MathArrayIndexOutOfBoundsException extending the JDK exception and
> >> then throw that directly?  
> > Do we really want to subclass all Java exceptions?
> > There was a discussion where I thought that we circumscribed all the types
> > of problems that would need CM exceptions to sublcass the standard ones.
> >
> > 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, 0, parameters.length);
> >   e.addMessage(INDEX, index);
> >   throw e;
> >
> >
> > Of course, "OutOfRangeException" cannot inherit from both
> > "IllegalArgumentException" and "IndexOutOfBoundsException"...
> 
> I thought about that, but would prefer to throw
> ArrayIndexOutOfBoundsException because that is really what is 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 the
> MathRuntimeException, note that it applies to all of the other
> 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, so
> 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 IAE is not
> appropriate (essentially why AIOB does not itself extend IAE).

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


Gilles

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


Re: [math] right way to throw IndexOutOfBoundsException?

Posted by Phil Steitz <ph...@gmail.com>.
On 8/7/11 11:38 PM, Gilles Sadowski wrote:
> On Sun, Aug 07, 2011 at 10:47:41PM -0700, Phil Steitz wrote:
>> I was about to do this:
>> throw MathRuntimeException.createArrayIndexOutOfBoundsException(
>>                     LocalizedFormats.OUT_OF_RANGE_SIMPLE, index, 0,
>> parameters.length);
>>
>> but remembered that this is now deprecated.  Do I need to add a
>> MathArrayIndexOutOfBoundsException extending the JDK exception and
>> then throw that directly?  
> Do we really want to subclass all Java exceptions?
> There was a discussion where I thought that we circumscribed all the types
> of problems that would need CM exceptions to sublcass the standard ones.
>
> 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, 0, parameters.length);
>   e.addMessage(INDEX, index);
>   throw e;
>
>
> Of course, "OutOfRangeException" cannot inherit from both
> "IllegalArgumentException" and "IndexOutOfBoundsException"...

I thought about that, but would prefer to throw
ArrayIndexOutOfBoundsException because that is really what is 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 the
MathRuntimeException, note that it applies to all of the other
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, so
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 IAE is not
appropriate (essentially why AIOB does not itself extend IAE).

Phil

Phil
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [math] right way to throw IndexOutOfBoundsException?

Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sun, Aug 07, 2011 at 10:47:41PM -0700, Phil Steitz wrote:
> I was about to do this:
> throw MathRuntimeException.createArrayIndexOutOfBoundsException(
>                     LocalizedFormats.OUT_OF_RANGE_SIMPLE, index, 0,
> parameters.length);
> 
> but remembered that this is now deprecated.  Do I need to add a
> MathArrayIndexOutOfBoundsException extending the JDK exception and
> then throw that directly?  

Do we really want to subclass all Java exceptions?
There was a discussion where I thought that we circumscribed all the types
of problems that would need CM exceptions to sublcass the standard ones.

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, 0, parameters.length);
  e.addMessage(INDEX, index);
  throw e;


Of course, "OutOfRangeException" cannot inherit from both
"IllegalArgumentException" and "IndexOutOfBoundsException"...


Gilles

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