> Checked exceptions don't count as stronger typing, they still don't force > you to deal with them correctly as an alternative to the expected return, > they occur in a shadow type system.
Huh I am confused, nothing exists that can force you to use subclassing "correctly", or equality etc. etc. In my head, the full name for "checked exceptions" is really "statically checked exceptions" because they are just plain runtime exceptions, except that the compiler will require that the author acknowledged secondary exit paths. I hence argue that since 1) acknowledging secondary exit paths does not in any way guarantee it's actually being handled, and 2) polluting method signatures has a stark influence on versionability and 3) when something is so massively misused, overused and misunderstood ...it's just a good idea gone bad. Reiniers idea is interesting, though here we go again with the mixed back of annotations and keywords. How about we simply loosen the chain a bit, making checked exceptions into warnings instead. IDE's and compilers will still complain, but now the busy programmer can stay on his primary train of thought without getting derailed. All existing code will remain backwards compatible and we may even use the existing @SuppressWarnings if we can't be bothered with the IDE or compiler flagging certain lines of code. Checked exceptions would go from being mandatory shackles to being advice on good behavior. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
