"An interesting idea that came out of last time we had this discussion was that the same exception could be checked or unchecked depending on where it's being used. The call site is obviously not the right place to do that, but the throw site might be. I'm still undecided on this whole idea."
Yep - no one agrees on what should be checked/unchecked. I personally would say never checked. Most agree SQL shouldn't be checked. And some think it depends on the usage. Has Sun/Oracle ever seriously considered doing anything about the Exception debacle? I submitted a request a ways back and it got shot down very quickly. I kind of think we're just stuck with Checked Exceptions as long as Java is used. I doubt any other language will pick up the feature, so eventually we'll be free of them. 2011/3/25 Cédric Beust ♔ <[email protected]> > > > On Fri, Mar 25, 2011 at 3:14 AM, mP <[email protected]> wrote: > >> >> RemoteException // probably the most famous this should be >> unchecked exception >> > > I disagree. RemoteException (and network exceptions in general) should be > checked exceptions. > > It's one of the things we learned from the seminal paper "A note on > distributed > computing"<http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.48.7969%26rep%3Drep1%26type%3Dpdf&rct=j&q=note%20distributed%20computing&ei=E-qMTYz6C4GosAPK6P2HCQ&usg=AFQjCNHGoeDsB773Zr-y7-kNiXpHKek0KQ&sig2=Nw6f57iV0vtWVLyHC1be9Q> > (PDF): > remote operations need to be clearly separated from local operations, and > the only robust way to do this is by enforcing the handling of errors > statically. If you're invoking a method and the invocation operation itself > (not the method) can fail, you need to handle it. > > > >> EOFException // checkness should be the same as IOException. >> >> Perhaps just perhaps the problem is that heirarchy is both a grouping >> mechanism and a way to define checkness. Therefore if a marker was applied >> to an exception to denote whether it (the exception) was checked or >> unchecked ignoring whether it extended exception/runtime etc perhaps things >> would be better and more flexible. > > > Yes, although all you need to achieve this goal is two different > hierarchies, which we already have. It's just a pity that such a huge chunk > of the inheritance tree belongs to the "checked" side. > > An interesting idea that came out of last time we had this discussion was > that the same exception could be checked or unchecked depending on where > it's being used. The call site is obviously not the right place to do that, > but the throw site might be. I'm still undecided on this whole idea. > > -- > Cédric > > > -- 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.
