harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Date Tue, 25 Apr 2006 03:20:38 GMT
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 <geir@pobox.com>:
>
>
> 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 <mloenko@gmail.com> 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 <vvgorr@gmail.com>:
> >>> 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 <mloenko@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> >>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>>>
> >>>>
> >>>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message