Sorry, as I've said I failed to find an exact example. Maybe because all exception incompatibilities were fixed early in the project beginning, or because they really had a small impact.
On Thu, Nov 19, 2009 at 5:38 PM, Tim Ellison <t.p.elli...@gmail.com> wrote: > On 18/Nov/2009 18:15, Jesse Wilson wrote: >> On Wed, Nov 18, 2009 at 10:07 AM, Tim Ellison <t.p.elli...@gmail.com> wrote: >>> Being consistent on checked exceptions like IOException is still >>> beneficial, >>> >>> and we should continue to maintain our current behaviour. >>> >>> Being consistent ... on throwing priority? So you are suggesting that >>> we continue to enforce priority order for multiple errors resulting in >>> exceptions outside the set above? >>> >>> Just trying to understand precisely what you are proposing. >> >> My focusing on a specific set of exceptions makes more complicated than >> necessary; sorry about that. Ultimately I agree with the RI's decision that >> it is bogus to either specify or enforce a particular exception priority. > > Shame, I thought you had something there, because I wonder about the > problems that may ensue if we allow the order of checked/unchecked > exceptions to change. > > For example, consider a stream's "read(buffer) throws IOException" > method. By definition the application code will have decided on some > way to handle the IOException. > > However, if there are multiple pre-condition errors such as the read() > being invoked on a closed stream, and the user passing in a null buffer. > The user code may very well care that the IOException is thrown early, > and handled, before the NullPointerException is thrown, and possibly > causing a crash. > > Regards, > Tim > -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://www.telecom-express.ru/ http://harmony.apache.org/ http://www.expressaas.com/ http://openmeetings.googlecode.com/
