harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Date Mon, 20 Feb 2006 12:34:38 GMT
I agree Anton, these are the right guiding principles and the proof will
be in running apps.

Regards,
Tim

Anton Avtamonov wrote:
> On 2/20/06, Mikhail Loenko <mloenko@gmail.com> wrote:
>> Well seems like we all agree with the general approach.
> 
> Yes. Agree.
> 
>> But...
>>
>> :)
>>
>> I do not agree with the specific case you describe: NPE vs. IAE.
>>
>> I can imagine a programmer who does not read the spec, who
>> does not want to check for null, who just makes 'catch NPE' somewhere
> 
> Mikhail, I definitely can imagine the same story. I only want to have
> such application first. Then we will be able to judge and decide what
> to do. Before that no need to deviate from spec (of cource, excepting
> the cases when spec itself contains bugs as in my example with
> GrayFilter when required exception is missed from spec).
> In your example, such 'professional' developer most likely catches
> just Exception rather then the particular one :-)
> 
>> And his app would work well on RI and fail with uncaught IAE on Harmony
>> if we follow the spec. So, what is the reason in this very specific case
>> to firmly follow the spec?
> 
> Because NPE (IMHO) is not well-defined way to inform the developer
> something is wrong with his/her code. It just shows 'something inside
> implementation' fails (excluding cases when NPE contains proper
> message and is thrown intentively).
> In opposite, IAE always shows programmer called the method with wrong
> input values. All is about better notation only.
> In case existing program specified percentage outside the reasonable
> range, for instance, and worked anyway it may be even better to
> clearly inform the developer something is wrong with the program.
> Because in reality there were no garantee that such incorrect code
> worked properly on Sun's impl: just a play of chance. Of course we
> should not add more exceptions than exist in code/spec (at least for
> now), but try to use 'proper' exceptions with better notation clear
> for the developers.
> 
> I propose to continue this discussion when we have real examples, i.e.
> real applications failed because of such differences or particular
> methods which can potentially fail applications... Otherwise the
> discussion is quite abstract... Just IMHO.
> 
> --
> Anton Avtamonov,
> Intel Middleware Products Division
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message