I'd back what Santiago said: > I think the design should not suffer from such a problem, as > the parent says. Only for trivial changes I'd rename an exception.
Thanks,. Mikhail 2006/4/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > > Vladimir Gorr wrote: > > Mikhail, > > > > I also thought about this scenario. However, if any TCK tests will fail due > > to this reason > > we cannot certify our product. Nobody will talk about the invalidity of TCK. > > Most likely we will update our sources. > > 1) I hadn't thought about this before, but it seems much cleaner to > throw A (rather than B extends A) if the spec says to throw A. > > 2) You can challenge TCK tests and have them eliminated. We've done it > for J2EE and other specs. I believe that we're going to be in for quite > a bit of it because for all practical purposes, we'll be the first use > of the TCK on an independent implementation of Java SE. > > geir > > > > > > Thanks, > > Vladimir. > > > > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > >> There is nothing about TCK here: if the spec requires to throw A > >> and we throw B that extends A then we follow the spec > >> > >> And if there is a TCK test that verifies that we throw A and only A > >> then the test is invalid and we will not have to pass it > >> > >> Sometimes it is an easy fix to throw A rather then B. > >> > >> But there could be two RI methods - one throwing A and another one > >> throwing B > >> such that in our implementation they both refer to some third method. > >> > >> In this case if we throw B in that 3rd method - then we conform the spec, > >> we won't break existing apps and it might cause design weakening > >> if we choose to go coping how RI works. > >> > >> So if the fix is easy then I'd agree to what folks say here, but in > >> general case > >> I'd not set the rule to follow RI this way. > >> > >> Thanks, > >> Mikhail > >> > >> 2006/4/24, Vladimir Gorr <[EMAIL PROTECTED]>: > >>> The answer to this question (in my opinion) depends on how TCK processes > >>> similar situations. > >>> If we want to successfully perform this suite on Harmony we should be > >>> compatible with RI. > >>> For certain there are a lot of tests into TCK will fail due to this > >> reason > >>> and we should be ready for this. > >>> > >>> Thanks, > >>> Vladimir. > >>> > >>> On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > >>>> Look at HARMONY-387. > >>>> > >>>> Example: > >>>> 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > >>>> Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > >>>> <0, while RI throws IndexOutOfBoundsException. > >>>> Specification mentions neither ArrayIndexOutOfBoundsException nor > >>>> IndexOutOfBoundsException. > >>>> > >>>> > >>>> Actually ArrayIndexOutOfBoundsException is a sub class of > >>>> IndexOutOfBoundsException. > >>>> > >>>> So the statement "both Harmony and RI throw IndexOutOfBoundsException" > >> is > >>>> true. > >>>> > >>>> But do we have to throw exactly those exceptions that are thrown by > >> RI? > >>>> > >>>> Can we throw > >>>> o.a.h.VMRisenNPE that extends NullPointerException? > >>>> > >>>> What if they throw kind of > >>>> sun.internal.SunFavoriteSubClassOfNullPointerException ? > >>>> > >>>> Thanks, > >>>> Mikhail > >>>> > >>>> --------------------------------------------------------------------- > >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> > >> --------------------------------------------------------------------- > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
