harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Date Tue, 25 Apr 2006 03:31:33 GMT
 > 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? :)
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.

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


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

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