harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Avtamonov" <anton.avtamo...@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 11:35:52 GMT
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

View raw message