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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
