Jimmy, Jing Lv wrote:
>> Geir Magnusson Jr wrote:
>>
>>
>> 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.
>>
> I agree.
> But there are at least two exceptional situation:
> 1) several exceptions throws from one method, which extend one parent
> class, e.g. ConnectionException and UnknownHostException, javadoc writes
> "throws IOException" rather than "throws
> ConnectionException,UnknownHostException". And in implementation, we
> shall throw them out directly instead of
> try{...
> }catch(UnknownHostException e){
> throw new IOException();
> }
> catch(ConnectionException e){
> throw new IOException();
> }
> right? :)
+1, and other instances where super-types or super-interfaces declare
compatible throws clauses that are implemented in subclasses that throw
more specific subtypes. I do not agree that we should be bound to throw
and exception of the identical type as the declaration.
> 2) and we may find some javadoc as "...then an unspecified error is
> thrown." For an example, in java.util.jar.Pack200.newPacker(). We can do
> nothing to meet such compatibility.
You can throw any Error to comply with that specification!
Regards,
Tim
> In summary, I think we shall follow doc in throwing exception; but if we
> find it inconvenient indeed or even impossible, let it be. :)
>
>> 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]
>>
>>
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
