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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
